12:57:41 <RRSAgent> RRSAgent has joined #tagmem
12:57:41 <RRSAgent> logging to http://www.w3.org/2013/03/18-tagmem-irc
12:57:43 <trackbot> RRSAgent, make logs public
12:57:45 <trackbot> Zakim, this will be TAG
12:57:45 <Zakim> ok, trackbot, I see TAG_f2f()8:00AM already started
12:57:46 <trackbot> Meeting: Technical Architecture Group Teleconference
12:57:46 <trackbot> Date: 18 March 2013
12:58:09 <JeniT> ScribeNick: JeniT
12:58:11 <JeniT> Chair: Noah Mendelsohn
12:58:29 <JeniT> Present: Yehuda, Anne, Yves, Peter, Ashok, Jeni, Noah
13:03:41 <JeniT> noah: introductions
13:04:07 <JeniT> wycats: jQuery foundation, web developer since 2003
13:04:27 <JeniT> annevk: elected as individual, now at Mozilla
13:05:05 <JeniT> annevk: was at Opera
13:05:15 <JeniT> annevk: worked on selectors API, CSS namespaces, DOM, URLs, Fetch specs
13:05:48 <JeniT> wycats: works on TC39, model system, gathering use cases
13:06:17 <JeniT> wycats: day job working on libraries
13:07:01 <Ashok> Ashok has joined #tagmem
13:07:09 <Zakim> +WG-meeting
13:07:16 <JeniT> s/model system/module system/
13:07:22 <annevk> Zakim, who is on the phone?
13:07:22 <Zakim> On the phone I see Masinter, WG-meeting
13:09:04 <JeniT> Yves: TAG team contact, and for WebApps
13:09:28 <JeniT> Yves: worked on HTTP 1.1 & HTTPbis, CSS (esp validator)
13:09:53 <JeniT> Yves: also web services
13:10:18 <JeniT> plinss: HP, CSS WG, full-time standards, was Netscape's rep
13:10:26 <JeniT> plinss: started the CSS namespaces spec for annevk
13:11:06 <JeniT> ashok: Oracle, XML Schema, XQuery, web services, linked data
13:11:17 <annevk> Yves, if it was up to me we'd remove the whole thing, but it was already too late :/
13:11:29 <JeniT> ashok: trying to standardise property graphs
13:12:35 <annevk> Jeni works for ODI, worked on XML Processing, Data & HTML, fragment identifiers
13:13:04 <noah> noah has joined #tagmem
13:13:34 <JeniT> Larry: Adobe, LISP, networked-mediated communication
13:14:02 <JeniT> Larry: URIs, URNs, HTTP 1.0 & related protocols
13:14:34 <JeniT> Larry: HTML, when it was at IETF
13:14:52 <JeniT> Larry: on advisory board for W3C & contributed to TAG charter
13:15:16 <JeniT> Larry: in IETF, URI schemes
13:15:57 <JeniT> noah: officially IBM, but with lots of other groups
13:16:13 <JeniT> noah: split between industry & academia, went to Lotus
13:17:03 <JeniT> noah: work with IBM & Sun on JavaBeans
13:17:20 <JeniT> noah: XML work
13:17:36 <JeniT> noah: hard to do clean work in large standards arena
13:18:40 <JeniT> noah: nice tradition of having diverse opinions on the TAG (people who disagree with Tim)
13:18:49 <JeniT> noah: now at Tufts teaching computer science
13:19:12 <JeniT> Topic: http://www.w3.org/2001/tag/2013/03/18-agenda#Convene
13:19:16 <Larry> http://larry.masinter.net
13:19:33 <JeniT> Topic: Brief Orientation
13:20:15 <JeniT> noah: agenda fluid, except that ht & jar only here after lunch tomorrow & Jeff at 11am tomorrow
13:20:36 <JeniT> noah: big things we will come back to on Wed
13:21:26 <slightlyoff> trying to call in...
13:21:29 <JeniT> noah: we represent broad community, should be aware of charter
13:21:57 <annevk> http://www.w3.org/2004/10/27-tag-charter.html
13:22:01 <annevk> charter ^^
13:22:30 <JeniT> noah: document & build consensus around web architecture & to interpret & clarify principles where necessary
13:22:41 <JeniT> noah: help community agree on what matters & how pieces fit together
13:22:53 <JeniT> noah: 2. resolve issues involving architectural principles
13:23:01 <JeniT> noah: both brought to the TAG & proactively
13:23:24 <Zakim> + +1.415.997.aaaa
13:23:31 <JeniT> noah: 3. coordinate cross-tech architecture developments inside & outside W3C
13:24:17 <noah> http://www.w3.org/2004/10/27-tag-charter.html#mission
13:24:45 <noah> http://www.w3.org/2004/10/27-tag-charter.html#mission
13:24:58 <JeniT> http://www.w3.org/2004/10/27-tag-charter.html#Mission
13:25:19 <JeniT> noah: we're not officially in the loop on spec approval
13:25:49 <JeniT> noah: will usually go direct to WGs about things we disagree with
13:26:02 <JeniT> noah: TimBL has ultimate say as Director
13:26:25 <JeniT> noah: one of our jobs is to advise him on occasion when he has to make decision
13:26:57 <JeniT> wycats: when we ran, slightlyoff & I interpreted "web architecture" to include architecture of web platform
13:27:23 <JeniT> wycats: it usually means how documents interlink etc
13:27:58 <JeniT> wycats: there's more recent developments around how platform works
13:28:14 <JeniT> wycats: there isn't a lot of architecture of the platform itself
13:28:35 <JeniT> noah: we've had several efforts, eg torgo's work on API minimisation
13:28:50 <JeniT> annevk: (to wycats) is your question about whether it means HTTP etc?
13:29:02 <JeniT> wycats: I'm asking about whether it means architecture of documents & their interactions
13:29:19 <JeniT> noah: web has grown from web of documents to web of other things, including active documents (ie scripts)
13:29:34 <Larry> how the web works: what's a server, client, using HTTP, separation of markup and style, the role of javascript. the 'architecture' of something describes the pieces and names the interfaces for how they're put together
13:29:41 <JeniT> noah: we did try to rewrite web arch around web applications
13:30:06 <JeniT> wycats: there's architecture of that web that is out there, and architecture of platform
13:30:11 <Zakim> -Alex
13:30:15 <JeniT> noah: can we delay until later in the F2F?
13:31:09 <JeniT> noah: the community builds specs, web built on them
13:31:36 <JeniT> noah: the pieces should fit together so that the web has a set of characteristics such as scalability, internationalisation etc
13:32:32 <JeniT> noah: I want us to remember that our remit is broad
13:32:54 <JeniT> noah: eg whether we can use URIs as if they mean something in 100 years, something the library community is concerned about
13:33:13 <JeniT> noah: probably not so relevant to browser community
13:33:37 <JeniT> noah: my job to smooth things along & make sure we deliver
13:33:46 <JeniT> annevk: how important is the charter?
13:34:12 <JeniT> annevk: eg it talks about using XML in a way that's no longer relevant
13:34:25 <JeniT> noah: not legalistic about it, but need to follow spirit
13:35:38 <Zakim> +Alex
13:35:49 <JeniT> Topic: Outreach to developer community
13:35:50 <JeniT> http://www.w3.org/2001/tag/2013/03/18-agenda#developersdevelopers
13:37:08 <JeniT> wycats: we'll have more luck outreaching to developers if what we do is stuff that affects their day-to-day lives
13:37:16 <noah> q?
13:37:52 <JeniT> plinss: I have a proposal: there's the webplatform.org project
13:37:57 <annevk> http://www.webplatform.org/
13:38:05 <Larry> +1 to peter
13:38:13 <JeniT> plinss: maybe we could have an architecture section on that site
13:38:36 <Larry> w3conf and webplatform.org represent new, significant addition of resources to build and maintain
13:38:43 <JeniT> noah: we have tried to do that previously, we assigned actions to do similar on the W3C site
13:38:47 <Larry> that's what's different
13:38:50 <JeniT> noah: almost never did them
13:38:53 <wycats__> q+
13:39:04 <JeniT> noah: is anyone interested in doing that?
13:39:12 <JeniT> wycats: I'm not sure web developers would find value from it
13:39:28 <JeniT> noah: when I teach, I like to point people at those things
13:39:42 <JeniT> wycats: specifically, webplatform.org is not a good platform for that
13:39:48 <noah> q?
13:39:54 <JeniT> plinss: I think it's evolving and it's trying to be that portal
13:40:06 <JeniT> plinss: if nothing else, some high-level overviews
13:40:11 <noah> q+ to talk about interaction vs. one way
13:40:16 <JeniT> wycats: like a list of concepts? here's what a URI is?
13:40:22 <Larry> i think this is an area where tag members are out of touch, webplatform.org is just starting, hasn't been filled out
13:40:34 <JeniT> plinss: yes, and how to use it, just broad strokes
13:40:45 <JeniT> ashok: could you extract it from the web arch document?
13:40:47 <noah> ack next
13:40:55 <JeniT> plinss: yes
13:41:16 <JeniT> wycats: my sense is that if we want to educate developers about web arch
13:41:42 <JeniT> … they see it as it actually works, eg POST can be used to delete resources
13:42:07 <JeniT> … danger of telling people how it works when it is out of touch with reality
13:42:15 <JeniT> plinss: yes, you have to be pragmatic
13:42:26 <JeniT> … eg the hashbang thing is a hack
13:42:44 <JeniT> … we should document it, say it's a hack, show the way forward to the right way
13:43:03 <JeniT> wycats: yes, say that the architecture of the web *right now* involves the hack
13:43:11 <JeniT> plinss: yes, and show the migration path
13:43:11 <noah> ack next
13:43:12 <Zakim> noah, you wanted to talk about interaction vs. one way
13:43:20 <JeniT> wycats: calling out the things that work today but that are hacks
13:43:28 <JeniT> … particularly useful to know what bits are hacks
13:43:48 <JeniT> noah: right relationship with developers is a discussion rather than one way
13:44:01 <JeniT> … webplatform.org isn't right because it's one way
13:44:22 <JeniT> … been at our best when we've worked with others
13:44:34 <JeniT> … good tension between short-term focus & long-term view
13:44:54 <JeniT> … architecture is about taking long-term view
13:45:13 <JeniT> … it's really hard because you don't get the immediate feedback
13:45:27 <wycats__> it turned out that it has poor adoption characteristics
13:46:02 <wycats__> q+
13:46:29 <JeniT> … good architecture usually boils down to use cases, should be examples about what breaks
13:46:50 <JeniT> annevk: important to understand why the confusion happens
13:46:50 <Larry> q+ to give a different description of "architecture"
13:47:05 <JeniT> annevk: eg a elements don't have way of specifying method
13:48:15 <JeniT> noah: need to be asking the question "are we doing anything we'll regret in 10 years"
13:48:16 <Larry> i think talking about GET vs POST belongs to the HTTP working group and that it was a waste of TAG time to talk about it
13:48:32 <JeniT> wycats: bringing it back to topic of developer outreach
13:49:06 <JeniT> … think there's high leverage in reaching out to platform developers (eg Rails, jQuery)
13:49:07 <Larry> best instance of successful developer outreach was http://www.w3.org/conf/
13:49:13 <JeniT> … to make it easy for developers to do the right thing
13:49:27 <noah> q?
13:49:30 <noah> ack next
13:49:35 <JeniT> … eg Rails team very interested in getting guidance on REST etc
13:49:42 <JeniT> … we still have to guess sometimes
13:49:57 <JeniT> … target the tools that people are using to build the sites
13:50:18 <JeniT> … this is about adoption characteristics, don't have to address everyone in the universe
13:50:33 <JeniT> noah: TimBL's design notes are a great resource, something TAG has done is write them up
13:50:43 <noah> ack next
13:50:44 <Zakim> Larry, you wanted to give a different description of "architecture"
13:50:55 <JeniT> wycats: it's not well known that eg the web arch document exists
13:51:17 <JeniT> Larry: architecture is about what pieces there are and how they connect together
13:51:34 <JeniT> … eg markup, style, scripting, client-server protocol
13:51:50 <JeniT> … principles are guidelines for how to use the architecture, or misuse it, things you should & shouldn't do
13:51:53 <noah> q?
13:51:58 <JeniT> … as a result of telling developers about the fundamentals
13:52:10 <JeniT> … someone new to the web needs to understand how the pieces interact
13:52:21 <JeniT> … GET vs POST is at too low a level, not a great use of TAG time
13:52:39 <JeniT> … architecture has changed significantly since Tim designed it, because of introduction of AJAX, scripting paradigm
13:52:47 <JeniT> … HTML now an API with a little bit of parsing
13:53:12 <noah> q?
13:53:59 <JeniT> slightlyoff: worth understanding economics that constituencies find themselves in
13:54:16 <JeniT> ... touched on that around current constraints vs futures
13:54:27 <JeniT> ... people are publishing content for parochial reasons
13:54:36 <JeniT> ... want to create value for a set of users
13:54:44 <JeniT> ... architecture enables or disables them from doing that
13:54:53 <JeniT> ... want to maximise benefits & minimise costs
13:55:15 <JeniT> ... have to be informed by what people are trying to get done
13:55:28 <JeniT> ... second point is that AJAX isn't a completely different architecture
13:55:41 <JeniT> ... means we have to recognise imperative layer
13:55:41 <noah> q+ to say why ajax does change things
13:55:47 <noah> q?
13:55:50 <noah> ack next
13:55:51 <Zakim> noah, you wanted to say why ajax does change things
13:56:05 <JeniT> noah: on AJAX, we have found places where it changes things
13:56:15 <Larry> "origin" and CORS need to be part of webarch
13:56:17 <JeniT> ... eg one principle is identifying things with URIs
13:56:26 <wycats__> q+
13:56:29 <annevk> Larry: working on it: http://fetch.spec.whatwg.org/
13:56:31 <JeniT> ... question about "what do you identify using an AJAX app"?
13:56:41 <Yves> s/:/,
13:56:42 <JeniT> ... eg states in a game
13:56:57 <Larry> annevk: "part of webarch"
13:57:15 <JeniT> ... if it's something that would have been done using the normal web architecture, still want to use URIs
13:57:16 <Larry> i don't mean "specified in webarch"
13:57:20 <JeniT> ... same with web storage
13:57:33 <JeniT> ... still need to identify these things with URIs
13:57:40 <annevk> Larry: fair enough
13:57:46 <JeniT> ... these are architectural questions
13:58:09 <JeniT> annevk: when would you not use HTTP requests?
13:58:32 <JeniT> noah: some of the web sockets stuff for example
13:58:45 <Larry> i mean that there's no place in the current webarch to talk about 'origin'
13:59:07 <Larry> i think URIs are less important to webarch as they were 10 years ago
13:59:10 <JeniT> wycats: one way to address the concern around local storage is to ask how can we make it really easy to use URIs for that
13:59:34 <JeniT> noah: not everyone agrees that's even what we should be aiming for
13:59:57 <JeniT> wycats: naming things with URIs is a fundamental part of the web
14:00:10 <JeniT> noah: let's have a proper session on URIs, AJAX etc later
14:00:42 <JeniT> slightlyoff: wycats, annevk & I have done work on this we could discuss
14:00:59 <JeniT> wycats: this is something that developers do understand, but they don't understand what it means to have a URI for an AJAX app
14:01:11 <JeniT> ... so this is something where we could have a good impact
14:02:20 <ht> ht has joined #tagmem
14:05:57 <Larry> i think "is it OK?" formulation isn't useful here
14:07:56 <slightlyoff> it IS a capability system
14:09:37 <Larry> noah: people use URIs for capabilities. it's part of how wthings work
14:10:17 <Larry> secrecy is measured in time-to-expiration
14:10:30 <Larry> uris can be secret for a little while
14:10:42 <Larry> time-to-compromise
14:11:17 <Larry> some really well encrypted channels have a time-to-compromise of decades (some people believe centuries, but i don't believe that)
14:11:48 <Larry> webarch also needs security properties everywhere
14:15:23 <timbl> timbl has joined #tagmem
14:16:01 <JeniT> Topic: Layering
14:16:03 <JeniT> http://www.w3.org/2001/tag/2013/03/18-agenda#layering
14:18:04 <wycats__> Here is the deck: http://cl.ly/3P3K3C3E422C
14:18:41 <slightlyoff> heh
14:19:02 <JeniT> wycats: trying to unpack what we meant by "Layering" when we ran for TAG
14:19:12 <JeniT> ... watched TimBL's TED talks
14:19:30 <JeniT> ... wanted to talk about how AJAX stuff links up with linked data & open data
14:19:51 <JeniT> ... first documents were hand-written documents, like we post via CVS
14:20:09 <JeniT> ... the data is the same as the markup, no translation layer
14:20:38 <JeniT> ... people realised they didn't want to have to write everything by hand, so started to separate out data and template, combined to create document
14:20:46 <JeniT> ... this obscures some of the raw data
14:21:08 <JeniT> ... as JS came into the frame, even the document provided via HTTP doesn't include the content
14:21:20 <JeniT> ... now need to run JS to get the "content" of the document
14:21:36 <JeniT> ... less and less of the document is content, more and more generated by JS
14:22:06 <JeniT> ... other side of this is that it's the *data* that is published by the servers
14:22:14 <JeniT> ... the semantic content is exposed
14:22:26 <JeniT> ... JS is about displaying that semantic content to the user
14:22:42 <JeniT> ... going to show discourse, form software built as a JS app
14:22:53 <JeniT> ... URL friendly, but all the communication is done via APIs
14:23:00 <JeniT> ... downloadable page is nothing (nothing in HTML)
14:23:11 <JeniT> ... rich semantic JSON sent to the client, devoid of display semantics
14:23:26 <JeniT> ... other end of the spectrum from markup is data, end up doing API first development
14:23:42 <JeniT> ... should be excited about this development if you like linked data
14:24:04 <JeniT> ... we shouldn't be scared of JS
14:24:13 <JeniT> ... "Where We Are Today"
14:25:03 <JeniT> ... people writing specs are writing implementations, think in terms of implementation
14:25:25 <JeniT> ... platform capabilities are exposed via markup & DOM bindings (JS code)
14:26:14 <JeniT> ... markup mapped to DOM, JS code interacts with it, display doesn't link with that JS bindings
14:26:23 <JeniT> ... JS bindings & rendering don't interact
14:26:52 <JeniT> ... eg simple form for POSTing info about people
14:28:24 <JeniT> ... the HTML spec defines how the input fields are displayed
14:28:29 <JeniT> ... one big case statement
14:28:41 <JeniT> ... want to add something new, have to add a new case
14:29:10 <JeniT> ... problem is that if you want to build your own controls, eg date picker
14:29:24 <JeniT> ... algorithm doesn't delegate to you
14:29:32 <slightlyoff> indeed, serialization is pluggable inside most implementations!
14:29:34 <JeniT> ... specification mirrors implementation rather than well-designed architecture
14:29:52 <JeniT> timbl: you're making assumption that you want to burrow all the way down
14:30:03 <slightlyoff> I can't hear timbl
14:30:30 <JeniT> ... even if it was implemented in JS it can be an architectural feature that you can't control everything
14:30:37 <slightlyoff> nobody's arguing against the value of standards
14:30:47 <JeniT> wycats: the answer isn't that "everything is JS"
14:30:51 <slightlyoff> at least not me or wycats__ ;-)
14:31:06 <JeniT> ... custom controls in jQuery
14:31:32 <slightlyoff> other toolkits do exactly this
14:31:37 <slightlyoff> (i've written this code multiple times)
14:31:57 <JeniT> ... create some hidden markup & use script to make it behave the way you want to
14:32:12 <slightlyoff> I also wrote this code in Dojo
14:32:18 <slightlyoff> (the serialization system)
14:32:34 <slightlyoff> Closure has the same split
14:32:53 <JeniT> ... serialize() in jQuery, to create form submission
14:33:11 <JeniT> ... need to write lots of imperative code to hack around the constrained browser capabilities
14:33:21 <noah> q?
14:33:27 <JeniT> ... people end up writing the whole browser in JS
14:33:34 <noah> q- wycats__
14:34:05 <JeniT> ... "Appeal to Magic"
14:34:23 <JeniT> ... form serialisation is the exact implementation in C++
14:34:38 <Larry> is SVG as its own content-type part of webarch?
14:34:57 <JeniT> ... people understand the core value propositions of the web, work hard to implement them in script
14:35:25 <JeniT> ... people don't do everything in canvas, but write lots of JS to emulate stuff that's part of the core web platform
14:35:33 <slightlyoff> once again, I can attest to this from the perspective of Google properties
14:35:33 <JeniT> http://meta.discourse.org/
14:36:16 <JeniT> wycats: URLs update as you scroll down the page
14:36:32 <JeniT> noah: this is a great example of what we've been advocating
14:36:53 <JeniT> wycats: the amount of JS necessary to do this is 962kb
14:37:12 <JeniT> ... would prefer to hook into primitives of the platform to get this to work
14:37:50 <JeniT> ... people discontented with having to write so much JS to do what should be built-in
14:38:01 <JeniT> ... "so close and yet so far"
14:38:23 <JeniT> ... in Rails we have something that reimplements browser navigation using XHR
14:38:27 <JeniT> ... to get better performance
14:38:42 <JeniT> ... end up doing crazy hacks to augment what the platform is doing
14:39:11 <timbl> https://github.com/chad/turbulence
14:39:18 <JeniT> ... users are frustrated when emulated layers don't work well
14:40:02 <JeniT> ... examples of twitter & Facebook, falling back from emulation
14:40:50 <JeniT> ... big picture of twitter going to native web pages is that they are giving up on good user experience
14:41:10 <slightlyoff> put another way: taking control, today, means taking *everything* under your JS-driven roof
14:41:29 <slightlyoff> tweetdeck is still native on their native platforms
14:41:31 <Larry> tweetdeck was Adobe AIR
14:41:33 <slightlyoff> (iOS, Android)
14:41:34 <JeniT> ... twitter/Facebook say "if you want to have a good user experience use a native app"
14:41:49 <slightlyoff> it's HTML5 on web.tweetdeck.com and their Chrome app
14:42:04 <Larry> http://en.wikipedia.org/wiki/TweetDeck
14:42:23 <JeniT> timbl: one of the things here is page load time, comparing that to a local application is cheating
14:42:34 <JeniT> ... need to install the app locally to get the speed
14:43:05 <JeniT> wycats: they were using caching etc, so trying, but you still have first page load hit for people finding tweets via google
14:43:23 <JeniT> ... web is a more casual browsing experience than the installation of applications
14:43:33 <JeniT> ... do not expect to have to install when they hit pages
14:43:46 <JeniT> annevk: where does twitter advocate using native apps?
14:43:57 <JeniT> wycats: not in this blog post
14:44:11 <JeniT> annevk: how do we get both the speed and the user experience?
14:44:14 <JeniT> wycats: I'm getting there
14:44:35 <JeniT> noah: two problems: having to download loads of JS & having to write loads of JS
14:45:15 <JeniT> wycats: reasonable to have a more installable model
14:45:20 <noah> q?
14:45:36 <slightlyoff> q+
14:45:41 <timbl> http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html
14:45:45 <JeniT> ... size is a particular issue in mobile & outside developed world
14:45:55 <noah> q?
14:46:22 <JeniT> ... shouldn't underestimate cost of malaise, result is less engaging apps
14:46:24 <noah> ack next
14:46:40 <JeniT> slightlylate: speaking from Google experience, eg desktop Gmail on the web
14:46:57 <JeniT> ... something like megabyte of JS, mostly is stuff the web should be better at
14:47:04 <Larry> does TAG want to take on web performance? takes optimizing rendering, download, network latency, javascript performance. "Velocity" conference
14:47:09 <JeniT> s/slightlylate/slightlyoff/
14:47:59 <JeniT> slightlyoff: spent an enormous amount of effort to reduce load time & impact of the wait
14:48:23 <JeniT> ... the constraints are the same even for massive organisations like Google
14:48:41 <JeniT> ... can't do as much as a native app can
14:48:56 <JeniT> wycats: looking at popular apps built using backbone/ember/angular
14:49:11 <JeniT> ... apps are around 700k
14:49:56 <JeniT> slightlyoff: limits are much lower on mobile devices
14:50:12 <JeniT> wycats: "Turing Escape Hatch"
14:50:26 <JeniT> ... people ask for primitives
14:50:40 <JeniT> ... example of mouse vs touchpad
14:51:24 <JeniT> ... eg tapping on iPad vs with mouse --- no :active on div
14:51:41 <JeniT> noah: this is about mapping that browsers have chosen in iPad
14:52:08 <JeniT> wycats: can add .active rather than using :active to hack around it
14:52:21 <JeniT> ... :active applies when "the element is being activated by the user"
14:52:28 <JeniT> ... this is appeal to magic
14:53:15 <annevk> q+
14:54:17 <JeniT> annevk: we have talked about how to spec this
14:54:43 <JeniT> ... complexities around scrolling
14:54:44 <slightlyoff> agree!
14:54:49 <JeniT> +1
14:55:01 <JeniT> annevk: these are HTML4-era specs
14:55:16 <JeniT> wycats: even in more modern specs there are huge failures in layering
14:55:30 <JeniT> ... there's a theory of layering that leads us to do the right thing
14:55:45 <JeniT> noah: I assume that these specs were written when the impact of iPads etc wasn't clear
14:56:01 <JeniT> ... could people have gotten this right?
14:56:08 <slightlyoff> yes
14:56:33 <JeniT> wycats: there should be some JS property somewhere that says that an element is active, so you can call it
14:56:48 <JeniT> slightlyoff: in the implementation there is an imperative version of this declarative form
14:56:59 <JeniT> ... the question is how exposed is that declarative form to the imperative world
14:57:08 <JeniT> ... there's going to be a translation somewhere
14:57:31 <JeniT> ... it's straight-forward to say that you need to add the imperative form at some point
14:58:00 <JeniT> timbl: by explanation, you mean you must be able to reroute the code
14:58:29 <JeniT> wycats: you must be able to not appeal to C++
14:59:20 <JeniT> noah: you need to be able to keep some of it, need to choose where you have the layer
14:59:32 <slightlyoff> back
14:59:48 <JeniT> ... end up with huge UI frameworks, where the purpose is to theme etc
15:00:15 <slightlyoff> q+
15:00:19 <annevk> q-
15:00:24 <slightlyoff> q-
15:00:36 <JeniT> wycats: platform built around C++ DOM
15:00:48 <JeniT> ... "Fundamental Theorem of the Platform"
15:00:51 <annevk> (I think the main problem is that we don't even understand, in documented manner, what the actual user interaction model is. User agents reverse engineer this from each other at the moment.)
15:01:06 <JeniT> ... "Markup begets JavaScript objects via a parser"
15:01:32 <JeniT> ... should be theorem that explains what the platform is doing that helps us define declarative/imperative split
15:01:50 <JeniT> ... stack of markup, JS runtime, DOM standard library, rendering
15:02:03 <JeniT> ... rendering defined in terms of platform primitives eg canvas
15:02:17 <JeniT> ... this matches web developers' mental model
15:02:24 <JeniT> ... gives us reasonable hook
15:02:41 <JeniT> annevk: this doesn't allow for asynchronous <something>
15:02:52 <annevk> ^^ selector matching
15:03:07 <JeniT> wycats: this isn't getting 100% perfect, just getting magic part smaller
15:03:16 <bkardell_> bkardell_ has joined #tagmem
15:03:56 <JeniT> slightlyoff: creating a competitive platform, we have technical question of accomplishing most value with least effort
15:04:15 <JeniT> ... not about replacing everything, about doing archeology & explaining in terms of more primitive APIs
15:04:37 <JeniT> ... some might not be exposed, but this is a powerful exercise in creating generative platform
15:05:10 <JeniT> noah: in these architectures, one thing you might want to do is encouraging people to do the XML thing and creating lots of new tags
15:05:20 <JeniT> wycats: yes, that's what I'm getting to
15:05:28 <JeniT> ... "Path for Natural Platform Evolution"
15:05:43 <JeniT> ... we don't want people to write everything using these primitive forms eg using canvas
15:06:16 <JeniT> ... provide some markup, people write imperative extensions, new "slang" markup, broad acceptance
15:06:34 <JeniT> ... we want to allow people to experiment with new tags
15:06:39 <slightlyoff> more to the point, we can't prevent it
15:06:41 <slightlyoff> and haven't so far
15:06:51 <noah> q?
15:06:55 <JeniT> ... if they become acceptable, they get rolled into the platform
15:07:10 <JeniT> ... provide a mechanism for evolutionary development that doesn't rely on Hixie
15:07:27 <slightlyoff> here's a preview of what that reserach might look like: http://meaningless-stats.appspot.com/global
15:07:32 <JeniT> ... can look at pages on internet to see what's being used
15:07:57 <slightlyoff> q+
15:08:06 <JeniT> noah: would you encourage people to experiment with tags that might become part of the platform, where's the cut-off about what you can use
15:08:15 <slightlyoff> https://github.com/slightlyoff/meaningless
15:08:18 <JeniT> timbl: what if you have a serious community eg MathML & Geo communities
15:08:35 <JeniT> ... broad acceptance in their communities, but not across whole planet
15:08:42 <JeniT> ... what's the world in which there are pieces of these?
15:09:01 <JeniT> wycats: I would imagine they would create their own extensions
15:09:07 <JeniT> timbl: would it be a browser extension?
15:09:25 <JeniT> wycats: can imagine in different levels of broad acceptance leading to different levels in browser support
15:09:44 <JeniT> timbl: I'm particularly interested in things that are completely accepted in a small community
15:09:56 <JeniT> wycats: the question is at what point it gets pulled into C++ code
15:10:02 <noah> I mostly like where Yehuda is going, but I'm nervous about the ability to (a) encourage communities doing things like MathML to standardize while (b) telling dentists that a <jaw> tag is not what this is about. One persons's horizontal can be another's vertical.
15:10:04 <JeniT> timbl: there are lots of communities doing exciting things
15:10:12 <slightlyoff> the point is we're not doing this with data today
15:10:20 <slightlyoff> we're doing conjecture, not science
15:10:27 <JeniT> ... like the geospatial folks, but they will not ever get into every browser
15:10:28 <slightlyoff> q+
15:10:28 <Larry> "chemical ml" and "math ml" are good examples
15:10:36 <JeniT> wycats: they could just have a JS library
15:10:44 <noah> This might well lead us back to and XML-like architecture, albeit with dynamic Javascript support (which is cool), but without namespaces or a distributed extensibility model.
15:10:48 <JeniT> ... or they could have a browser extension that would make available & cache the JS library
15:10:56 <JeniT> timbl: and maybe reimplemented in C++
15:11:22 <JeniT> slightlyoff: I posted a reporting site for a Chrome extension to start looking at the ad-hocs semantics in the web at the moment
15:11:34 <JeniT> ... we haven't stopped anyone adding semantics to HTML
15:11:42 <noah> I might agree that living without something like namespaces is OK for things that may become core to the platform, when you get too close to vertical (dentists), you really need some way to keep names straight, and to enable mixins.
15:11:45 <JeniT> ... we've made it difficult enough that people don't agree on how to express them
15:11:56 <noah> q?
15:11:58 <noah> ack next
15:11:59 <JeniT> ... the goal is not to repeat the perceived mistakes of XML world
15:12:21 <JeniT> ... it's to generate the visual/content meaning from the markup
15:12:49 <JeniT> ... we don't have today a good way to tie the creation of end-user value to new declarative forms
15:13:19 <JeniT> ... hard to track use of declarative form because people use imperative form
15:13:31 <Larry> JSON is a "declarative form"
15:13:32 <JeniT> ... give tools to start declarative
15:13:44 <JeniT> ... can then start to do science on the web to detect patterns
15:13:55 <JeniT> ... at the moment we can't do this because it's hidden in the imperative code
15:14:09 <JeniT> wycats: an Ember template looks like a minified JS function, for example
15:14:22 <JeniT> ... final example is different from markup
15:14:32 <JeniT> ... offline downloadable case
15:14:38 <JeniT> ... step one was App Cache
15:14:45 <JeniT> ... Apple used this at beginning of iOS
15:14:53 <slightlyoff> this markup system, btw, is my work from Web Components
15:15:10 <JeniT> ... App Cache declarative form with no imperative escape hatch
15:15:17 <JeniT> ... Hixie built declarative form
15:15:35 <JeniT> ... large number of workshops to fix what's broken with App Cache
15:15:57 <Larry> public-fixing-appcache@w3.org
15:16:17 <JeniT> ... Hixie wasn't interested in implementing it
15:16:31 <Larry> http://www.w3.org/community/fixing-appcache/
15:16:42 <JeniT> ... platform already has capability, but because it was drafted wrong, we're not able to use it
15:17:14 <Larry> http://www.w3.org/community/fixing-appcache/2013/02/11/moving-further-spec-development-to-webapps-and-closing-the-cg/
15:17:28 <JeniT> ... if there's no escape hatch we can't easily fix/hack around these
15:17:32 <slightlyoff> you weld it shut if your view is that the platform is a hermetic thing without layering
15:17:52 <JeniT> ... need platform features that are broadly useful rather than targeted on specific features
15:17:57 <JeniT> ... "Navigation Controller"
15:18:15 <JeniT> ... questions when you write an offline app
15:18:32 <JeniT> ... what happens when they first load the page, first time, subsequent times, how does the cache work?
15:18:44 <JeniT> ... Navigation Controller provides the answer, but also way to override
15:19:19 <JeniT> noah: is this defined in terms of an HTTP cache?
15:19:59 <JeniT> slightlyoff: no
15:20:26 <JeniT> slightlyoff: turning big case into small primitives, if they're not implemented fall back on default behaviour
15:20:56 <JeniT> wycats: App Cache implemented on top of something where behaviour can be overridden
15:21:16 <JeniT> noah: HTTP caches are implementations of HTTP spec, built into browsers
15:21:26 <JeniT> ... not focused on long-term caching
15:21:42 <JeniT> ... be interesting to tell an organised story about how what we do relates to those headers and that architecture
15:21:50 <JeniT> ... should be a lot in common
15:22:21 <JeniT> ... need a clean story where this is consistent with this architecture
15:22:28 <JeniT> annevk: need to define the interaction anyway
15:22:34 <JeniT> noah: look at both spec and code point of view
15:22:44 <JeniT> wycats: I think it does talk about interaction with HTTP cache now
15:23:05 <JeniT> annevk: if there's a POST, you want to store it in the Controller in the offline case, which HTTP caches won't do
15:23:25 <JeniT> wycats: use existing browser primitives, build on top of them
15:23:42 <JeniT> ... need core primitive of "opaque response" for example
15:24:06 <JeniT> ... we might not like how it works, but we need to explain how it works
15:24:20 <JeniT> ashok: is this how you think it *should* work, or how it *does* work?
15:24:34 <JeniT> wycats: this is a proposal that Alex is creating, a proposal that Alex will make to a real WG
15:24:54 <JeniT> ... "Declarative Form"
15:25:07 <JeniT> ... Jonas Sicking has been working on better declarative API
15:25:12 <JeniT> ... it's a JSON model
15:25:20 <JeniT> ... one problem with App Cache was that it wasn't extensible
15:25:29 <JeniT> ... using JSON means we don't have to amend the parser
15:25:40 <slightlyoff> brb
15:25:40 <JeniT> ... it's less ambitious
15:26:11 <JeniT> ... provides just the obvious things, so we can explore how it is actually used
15:27:09 <JeniT> ... includes mechanism for templated URLs & use of XHR
15:27:36 <JeniT> ... lets you point to markup & data separately
15:27:49 <JeniT> ... "Evolution"
15:27:58 <JeniT> ... people will extend JSON, add JS libraries etc
15:28:03 <JeniT> ... use this to evolve the platform
15:28:26 <JeniT> ... better imperative capabilities enables better evolution
15:28:37 <JeniT> ... I'll not talk about web components much
15:28:46 <JeniT> ... these are basically the same thing
15:29:10 <JeniT> ... I propose that we write a Recommendation that outlines this design philosophy for the web platform
15:29:24 <JeniT> Yves: going back to delegation controller & cache
15:29:41 <JeniT> ... if you look at local cache as being a URI resolver, then you see it as a low end version of a controller
15:29:54 <JeniT> ... there are things that are shared
15:30:06 <JeniT> wycats: yes, you could imagine that HTTP cache is defined as controller
15:30:41 <JeniT> noah: need few minutes discussion about where to go next
15:30:57 <slightlyoff> back
15:30:59 <JeniT> ... this would be a significant project for the TAG
15:31:47 <JeniT> ... for these we should have a project page:
15:31:49 <JeniT> ... goals
15:31:52 <JeniT> ... success criteria
15:32:09 <JeniT> ... a Rec is not a success criteria: explain in terms of what that achieves
15:32:16 <JeniT> ... key deliverables, dates, who's assigned
15:32:43 <JeniT> ... often useful at this point to create a first cut at what the product page might look like
15:32:59 <JeniT> ... use that as point of discussion about why we should do this, what the TAG's role is
15:33:29 <noah> Example of a product page: http://www.w3.org/2001/tag/products/fragids.html
15:33:34 <JeniT> wycats: all this stuff about Navigation Controller etc is just specific examples, we need to look at higher level
15:33:49 <JeniT> timbl: what's the push-back that you've heard around these ideas?
15:33:55 <JeniT> ... will the implementers get on board?
15:34:09 <JeniT> wycats: main pushback is from people worried about new imperative forms
15:34:23 <JeniT> s/imperative/declarative/
15:34:33 <noah> If this is to be a significant project, we need a plan at about that level. We don't necessarily need it at this F2F, but I'm suggesting we draft a strawperson version just to get discussion of what the scope and goals of the TAG's work on this might be.
15:34:48 <JeniT> slightlyoff: general lack of familiarity from implementers about what developers need
15:34:59 <JeniT> ... don't go from being web developers to browser implementers
15:35:03 <wycats__> noah: I volunteer to bring that back tomorrow or Wednesday
15:35:59 <JeniT> noah: great, we'll come back to this later in the F2F
15:36:37 <JeniT> annevk: the main concern I've heard about web components is lack of shared understanding
15:36:43 <JeniT> ... counter-argument is that we already don't
15:37:02 <noah> Great, thank you. Suggest you collaborate with others, at least informally.
15:37:11 <JeniT> ... also heard concern that if we only do low-level primitives, it'll be too hard for normal web developer
15:37:31 <JeniT> timbl: building up from bottom rather than down from top?
15:37:51 <JeniT> slightlyoff: this is an interesting question for the TAG: do you do one before the other?
15:37:53 <wycats__> you do both
15:38:11 <wycats__> but the high level is defined in terms of the primitives, like the app cache example
15:38:14 <JeniT> ... look at what opportunities you foreclose and how you reduce opportunity for harm
15:38:28 <JeniT> timbl: like with :active you could imagine it starting with touch events etc
15:38:54 <JeniT> ... need some top-down for device interoperability
15:39:12 <JeniT> ... if you start low-level people start generating different design abstractions
15:39:19 <JeniT> wycats: define high-level in terms of low-level
15:39:42 <JeniT> ... eg start with the element, then talk about what new capability is in JS objects
15:39:51 <JeniT> ... end up with high-level thing that's nice + escape valve
15:39:55 <JeniT> timbl: if you get it right, yes
15:40:12 <JeniT> annevk: another concern, around rendering, is that rendering doesn't happen on main thread
15:40:21 <JeniT> ... currently constraint-based system rather than imperative system
15:40:40 <JeniT> ... exposing it as a imperative system removes possibilities of optimisation
15:40:50 <JeniT> noah: try to keep as much of it as declarative as possible
15:41:05 <JeniT> ... eg changing CSS through adding class through JS
15:41:32 <JeniT> wycats: always going to be the case that if you are reimplementing something that's implemented in browser it's going to be slower
15:41:51 <JeniT> annevk: by defining the platform in a certain way, you might constrain it
15:42:19 <JeniT> ... might want to implement browser in a fancy different way, the single-threaded system is problematic
15:42:41 <JeniT> timbl: these sorts of problems: making something performant needs different implementation strategies
15:42:46 <JeniT> ... eg parallelisation
15:42:58 <slightlyoff> annevk: http://infrequently.org/12/cassowary-js-refactor/demos/css/canvas-renderer.html
15:43:11 <JeniT> ... asking for the callout can be difficult to implement
15:43:25 <JeniT> wycats: people are reimplementing the entire layout system in JS, surely that's not more performant
15:43:39 <JeniT> timbl: so prepared to hit on very fast reflow of CSS in order to be able to override it
15:44:16 <slightlyoff> annevk: it's possible to uncover the solver as a capability
15:44:58 <slightlyoff> annevk: going where the evidence leads
15:45:22 <slightlyoff> annevk: without pre-judging the level of abstraction you end up at
15:45:38 <annevk> slightlyoff: I meant e.g. the case bz mentioned where if you implemented the DOM completely in JS you could no longer do async selector matching
15:45:59 <slightlyoff> yeah, that's sort of BS
15:46:04 <annevk> slightlyoff: I don't really fully understand canvas-renderer.html
15:46:09 <slightlyoff> browsers always have fast-and-slow paths
15:46:18 <annevk> slightlyoff: euh sure
15:46:20 <slightlyoff> annevk: it's re-implementing CSS in JS via a JS constraint solver that I work on
15:46:33 <slightlyoff> annevk: but the conceptual level of abstraction need not be one level or the other
15:46:52 <slightlyoff> annevk: e.g., JS engines internally use single-static-assignment transforms
15:47:03 <slightlyoff> annevk: but JS is not a pure-functional language
15:47:16 <slightlyoff> and there are scenarios where you can't employ those xforms
15:47:18 <slightlyoff> and we get by
15:47:39 <annevk> I don't follow
15:47:48 <slightlyoff> going fast when we can based on some other formalism than the naive interpretation of "what it is"
15:48:20 <slightlyoff> +1!
15:48:40 <JeniT> ht, thanks, not sure I got it all
15:49:14 <ht> I wonder if there's a place here for what the XML-on-the-Web community has been doing for years has a place in this story, i.e. _declarative_ layering using XSLT in the browser
15:49:16 <slightlyoff> JeniT: are y'all breaking for lunch?
15:49:34 <ht> Yes, remote people need to know where we are in the schedule
15:50:08 <slightlyoff> yeah, but it sounds like you're not doing the agenda now
15:50:19 <slightlyoff> so this is a short break before JeniT's session?
15:50:41 <slightlyoff> thanks
15:51:55 <Zakim> +??P3
15:52:22 <Zakim> -Masinter
15:53:12 <JeniT> Topic: Fragment Identifiers
15:53:19 <JeniT> http://www.w3.org/2001/tag/2013/03/18-agenda#fragids
15:53:35 <JeniT> goals for this session: http://lists.w3.org/Archives/Public/www-tag/2013Mar/0059.html
15:54:46 <slightlyoff> so it would be good to know the plan. I need to move locations during your lunch break.
15:54:55 <slightlyoff> (else I won't be home before 8pm)
15:56:05 <noah> do scribenick annevk
15:56:07 <annevk> scibenick: annevk
15:56:11 <annevk> scribenick: annevk
15:56:46 <annevk> Topic: Fragment Identifiers (aka hash, fragids, .search)
15:56:52 <annevk> s/.search//
15:57:10 <annevk> JeniT: Goal if this session is to figure out what to do with the spec
15:57:18 <annevk> s/Goal if/Goal of/
15:57:27 <annevk> [see link above]
15:57:31 <JeniT> http://lists.w3.org/Archives/Public/www-tag/2013Feb/0021.html
15:58:03 <annevk> JeniT: RDF/XML clashes with RFC 3023bis
15:58:45 <annevk> JeniT: If you have a structured syntax like +xml or +json, then any media types that adopt that suffix need to comply with the suffix registration
15:59:16 <annevk> JeniT: generic XML processors should be able to use fragids without understanding context
15:59:37 <JeniT> http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2013-03-12.html
16:00:00 <annevk> JeniT: the spec (^) is written for four sets of people
16:00:28 <annevk> JeniT: registration of +suffix media types people (e.g. +xml); media type registration people (e.g. application/rdf+xml);
16:00:41 <annevk> JeniT: fragment structures which should work across media types
16:00:53 <annevk> JeniT: and the people who write code
16:00:55 <ht> Relevant bit of 3023bis is here: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-00#section-8.1 and here: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-00#section-5
16:01:34 <annevk> JeniT: Last Call was the last step
16:01:44 <annevk> JeniT: now up for CR for which we need exit criteria
16:01:57 <slightlyoff> just listening for now
16:02:46 <slightlyoff> yes, it is
16:02:58 <annevk> wycats__: my main issue is that in browsers fragids are often used for something else entirely
16:03:41 <annevk> JeniT: the focus is not for RESTful app developers  as that's addressed elsewhere
16:04:05 <annevk> timbl: don't you think the use of fragids might increase?
16:04:11 <annevk> wycats__: seems plausible
16:05:09 <annevk> wycats__: My concern is that a document about fragment identifiers should cover its main use, in HTML
16:05:20 <Ashok> q+
16:05:31 <ht> See also http://tools.ietf.org/html/rfc6839#section-4.1
16:05:50 <annevk> JeniT: it's up to the media type registration
16:08:39 <slightlyoff> I see this as a question about navigation
16:09:07 <wycats__> q+
16:09:12 <noah> q?
16:09:14 <annevk> annevk: I think there's a mismatch between the media type -> fragment mapping and what actually happens in a browser
16:09:33 <annevk> noah: is this in the edge case or is this not the architecture?
16:09:49 <annevk> noah: is this 80/20 or is the architecture really not correct?
16:09:55 <annevk> annevk: I think it's a 80/20
16:10:01 <JeniT> discussion about embedded images in iframe etc where browser captures control of the interpretation of fragids within that iframe
16:11:19 <noah> ack next
16:11:36 <ht> q+ to point to the IETF state of play
16:11:39 <annevk> noah: is it okay if we note that we point out it's not always accurate and we might do future work?
16:11:45 <timbl> q+
16:11:59 <annevk> Ashok: what if somebody does a registration and does not follow the rules?
16:12:27 <annevk> Yves: best practices still allow for people shooting themselves
16:12:34 <Zakim> -Alex
16:12:50 <Zakim> +Alex
16:12:59 <annevk> JeniT: media type registration people could check against this
16:13:24 <annevk> Ashok: does the IETF agree with us?
16:13:38 <annevk> JeniT: the feedback from the people involved suggests so
16:13:47 <annevk> JeniT: but they are not the reviewers
16:14:17 <annevk> JeniT: the exit criteria are what's important here
16:14:48 <annevk> JeniT: [goes through proposal]
16:15:18 <noah> Two tentantive agenda items added for Wed morning. See http://www.w3.org/2001/tag/2013/03/18-agenda.html
16:16:27 <annevk> plinss: CR is a call for impl so people should start using it
16:16:47 <slightlyoff> uh...I think wycats__ had a point ot make
16:16:50 <slightlyoff> we have time.
16:17:05 <slightlyoff> (all day, in fact)
16:17:52 <Zakim> +Masinter
16:18:23 <annevk> wycats__: A thing that happens in the world in the world where people request the same resource from a browser and with an Accept header via XHR to get JSON
16:18:47 <annevk> wycats__: if they use the same fragment, is that a problem?
16:19:38 <annevk> wycats__: I want it to be specifically allowed to use a fragment identifier for some media types and not others
16:19:47 <annevk> wycats__: in the context of content negotiation
16:20:13 <annevk> wycats__, so many reasons not to do content negotiation btw: http://wiki.whatwg.org/wiki/Why_not_conneg
16:20:27 <slightlyoff> annevk: conneg happens
16:20:35 <slightlyoff> annevk: honestly, it does
16:20:40 <annevk> doh
16:20:43 <slightlyoff> consenting adults and all that
16:21:03 <annevk> All I'm saying is that it's a bad idea
16:21:23 <annevk> E.g. confused proxies that don't support Vary
16:21:24 <wycats__> annevk: O_O
16:21:26 <slightlyoff> and I don't happen to agree = )
16:21:42 <wycats__> I disagree strongly with that document
16:21:55 <slightlyoff> in the same way I disagreed with crock's jslint recommendations
16:21:55 <annevk> wycats__, hope you read it first :)
16:21:58 <wycats__> And Rails/jQuery is an existence proof that this is not an issue
16:21:59 <wycats__> annevk: I did
16:22:06 <wycats__> I skimmed
16:22:10 <Larry> the exercise of thinking about exit criteria is important
16:22:26 <slightlyoff> ht sorry, my client was doing that
16:22:29 <slightlyoff> apologies
16:22:36 <noah> q?
16:22:44 <noah> Nuts, forgot about the queue, sorry.
16:22:53 <noah> q- wycats__
16:23:15 <annevk> Larry: your CR exit criteria proposal looks fine
16:23:48 <noah> ack next
16:23:49 <Zakim> ht, you wanted to point to the IETF state of play
16:23:56 <Larry> it matters less about the details but at least that there is some credible measure that you "got it right"
16:24:19 <slightlyoff> annevk conneg drives a huge amount of the web
16:24:27 <slightlyoff> annevk I think your document is simply a dead letter
16:24:35 <annevk> slightlyoff it's not mine
16:24:40 <annevk> slightlyoff I simply agree with it
16:24:44 <slightlyoff> annevk ok, still a dead letter = )
16:24:59 <JeniT> http://tools.ietf.org/html/rfc6839#section-4.1
16:25:00 <slightlyoff> annevk and agreeing with it won't revive it
16:25:43 <annevk> slightlyoff I don't think it's dead at all
16:25:51 <annevk> slightlyoff most of the new stuff has taken it into account
16:25:57 <JeniT> ht: this implements the best practices
16:26:27 <JeniT> http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-00#section-8.1
16:26:37 <annevk> JeniT: RFC3023bis has stalled due to lack of energy, but I now found that energy
16:26:45 <annevk> s/JeniT/ht/
16:26:55 <noah> q?
16:26:57 <slightlyoff> annevk sorry, it might reflect your reality but not most of the web, toolkits, etc.
16:27:04 <annevk> ht sorry about minutes :( so hard to hear
16:27:06 <slightlyoff> annevk so specs might write it in, but it doesn't make it right
16:27:15 <noah> q- timbl
16:27:35 <annevk> slightlyoff most of the web, I'd like to see that quantified
16:27:43 <annevk> slightlyoff e.g. most of the CDNs don't work this way
16:27:47 <slightlyoff> annevk by traffic? sure: gmail and google.com search
16:28:09 <annevk> slightlyoff they use the same URL with different representation?
16:28:17 <ht> http://tools.ietf.org/html/rfc6839 uses prose taken indirectly from earlier drafts of our doc't, and I think it can be counted as evidence of uptake wrt CR exit
16:28:20 <slightlyoff> annevk you bet
16:28:25 <Larry> the "elephant in the room" is that MIME in the web is under attack by sniffing and registerContentHandler
16:28:26 <annevk> hmm
16:28:43 <noah> q?
16:28:51 <annevk> timbl: I'd like to use fragment identifiers to be used in lots more places
16:29:35 <JeniT> browsers should implement http://tools.ietf.org/html/rfc5147
16:29:36 <annevk> timbl: e.g. I won't fragment identifiers for plain text and view-source:
16:29:59 <JeniT> s/won't/want
16:30:04 <JeniT> s/won't/want/
16:30:50 <Larry> +xml vs +json don't have common fragment identifiers
16:31:01 <noah> q?
16:31:06 <noah> q+ to mention ajax
16:31:26 <annevk> wycats__: Getting agreement on how to do this for text/plain might be tricky
16:32:36 <noah> q-
16:33:30 <annevk> timbl: My concern is that fragment identifiers are already in use in HTML for wildly different things and if we ask for them to have the same semantics as their you're breaking things.
16:33:52 <timbl> Henry is not practiced at having a limiter
16:34:09 <noah> I think the worry is conneg, Henry
16:34:16 <timbl> type it QUIETLY ;-)
16:34:25 <noah> Speak it silently.
16:34:38 <annevk> timbl: http://tools.ietf.org/html/rfc5147
16:35:41 <ht> I think it's important to keep the conneg issues and the suffix/generic issues carefully distinct
16:35:43 <Larry> polyglot fragment identifiers
16:36:07 <Larry> fragment identifiers that mean the 'same' when interpreted by content with different media types
16:36:15 <annevk> RRSAgent: draft minutes
16:36:15 <RRSAgent> I have made the request to generate http://www.w3.org/2013/03/18-tagmem-minutes.html annevk
16:36:17 <ht> There are similarities, along the lines that Jeni has just suggested, but they aren't the same
16:36:27 <Larry> q+ to point out this is a polyglot example
16:37:35 <wycats__> q+
16:37:44 <wycats__> q-
16:38:12 <Larry> q-
16:38:18 <annevk> JeniT: I think
16:38:25 <annevk> JeniT: we agree on the exit criteria
16:38:30 <annevk> JeniT: we agree to REC
16:38:35 <annevk> JeniT: there are concerns with
16:38:46 <annevk> JeniT: content negotiation and transitioning
16:39:02 <annevk> JeniT: HTML/XML where script takes over the interpretation
16:39:13 <annevk> JeniT: I will
16:39:23 <annevk> JeniT: create a new draft for a future TAG call soonish
16:39:41 <annevk> plinss: do these changes require another LC?
16:39:50 <annevk> noah and JeniT: no
16:40:05 <slightlyoff> I don't think we need another LC
16:40:56 <slightlyoff> I'm changing locations, so I'll call back in in an hour or so
16:42:15 <Zakim> -ht
16:42:17 <Zakim> -Masinter
16:43:50 <Zakim> -Alex
17:16:06 <JeniT> JeniT has joined #tagmem
17:30:53 <Zakim> +Alex
17:37:44 <noah> We're delaying 10 mins in hope Marcos will arrive
17:41:33 <ht> ht has joined #tagmem
17:46:22 <JeniT> Topic: ISSUE-24 Authoritative Metadata
17:46:28 <JeniT> ScribeNick: JeniT
17:48:05 <JeniT> annevk: TAG finding 2006 on "Authoritative Metadata"
17:48:09 <noah> http://www.w3.org/2001/tag/doc/mime-respect-20060412
17:48:26 <JeniT> ... argues that encapsulating metadata about content is more important than the content
17:48:34 <JeniT> timbl: that you can't understand content without having read it
17:48:49 <JeniT> annevk: in fact, browsers disregard content type sometimes
17:49:04 <JeniT> ... they look at content type and sniff content as well
17:49:18 <JeniT> ... because use the wrong content type
17:49:35 <JeniT> ... with img, the content type is basically ignored
17:49:50 <JeniT> ... test if it's image/svg, otherwise just pipe to image processor
17:50:01 <JeniT> ... video is similar, uses the bytes in the content to determine format
17:50:05 <JeniT> ... cache manifest does the same thing
17:50:14 <JeniT> noah: is there a lot of badly served video?
17:50:25 <JeniT> annevk: video is hairy because of how it's distributed
17:50:31 <JeniT> ... lots of different container formats
17:50:39 <JeniT> ... doesn't map that well to media type system
17:51:04 <JeniT> wycats: was a time, cache manifest was served wrong
17:51:09 <JeniT> <interrupt>
17:51:41 <JeniT> </interrupt>
17:52:06 <JeniT> annevk: with cache manifest we required correct media type, but people complained a lot, so we dropped the requirement
17:52:19 <JeniT> ... with subtitling, the webTTL format, we also decided to just look at first set of bits
17:52:40 <JeniT> ... we disregard content type for the response for these requests
17:52:44 <JeniT> ... fonts, same thing happens
17:52:56 <JeniT> ... tried to do fonts/X but IETF didn't help
17:53:03 <JeniT> ... browsers started shipping
17:53:11 <JeniT> ... people were using application/octet-stream
17:53:27 <JeniT> ... IETF had no interest in fonts/X
17:53:36 <slightlyoff> wait...what's important for CSP?
17:53:39 <JeniT> ... for CSV it's important
17:53:51 <JeniT> s/CSV/CSP/
17:53:57 <JeniT> ... content security policy
17:54:05 <slightlyoff> hmmm
17:54:06 <JeniT> ... trying to prevent XSS attacks
17:54:07 <slightlyoff> I'm not sure I agree
17:54:12 <Zakim> +Masinter
17:54:20 <slightlyoff> I'm contributing to CSP
17:54:26 <slightlyoff> and I don't understand how this is an issue
17:54:28 <JeniT> ... from a browser perspective, we wanted to enforce content-type
17:54:39 <JeniT> ... from a web developer perspective it's difficult
17:54:44 <Larry> talking about sniffing?
17:54:47 <JeniT> ... because you don't always have sufficient control
17:54:57 <slightlyoff> q+ I'd like to talk about CSP
17:55:01 <JeniT> marcosc: github doesn't give you any control for example
17:55:02 <slightlyoff> q+
17:55:11 <noah> e Hi Larry, we're just getting into authoritative metadata. Anne is giving us a summary of the state of play, which is basically: a lot of the new markup specifically ignores content type in some cases due to pushback when early versions required it
17:55:19 <JeniT> annevk: we don't want to interpret arbitrary files as CSS
17:55:28 <JeniT> ... there were hacks that took advantage of that
17:55:39 <JeniT> ... for cross-origin requests we enforce content type
17:55:49 <Larry> x-content-type-options: nosniff is a good idea
17:55:51 <slightlyoff> again, would like to dive into CSP
17:55:52 <JeniT> ... and in strict mode
17:56:10 <wycats__> q+
17:56:17 <JeniT> ... CSS is easier to enforce because it's been around for a long time
17:56:22 <noah> ack next
17:56:33 <JeniT> slightlyoff: I'd like to dive into the CSP question, because I don't understand the issue
17:56:45 <JeniT> ... CSP defines what origin what sort of content can be from
17:56:53 <JeniT> ... that's about execution
17:57:01 <JeniT> ... that doesn't speak to mime types
17:57:09 <JeniT> annevk: CSP is authoritative metadata
17:57:15 <noah> Curious, is content-type honored on script tags?
17:57:18 <JeniT> ... we want that metadata to be authoritative
17:57:34 <JeniT> slightlyoff: I see, you're not talking about content type here, you're talking about the CSP header
17:58:15 <JeniT> noah: we're on a thread with darobin saying that authoritative metadata is an anti-pattern
17:58:15 <slightlyoff> I don't see how <script> is bad either
17:58:29 <slightlyoff> sending an image and having it pulled in is just fine
17:58:50 <noah> Quoting from Robin's email of http://lists.w3.org/Archives/Public/www-tag/2013Feb/0114.html
17:58:55 <Larry> there are a ton of problems with the sniffing document
17:58:57 <noah> "I would support the TAG revisiting the topic of Authoritative Metadata,
17:58:57 <noah> but with a view on pointing out that it is an architectural antipattern. "
17:58:57 <JeniT> annevk: there's an argument that we should be looking at something else because it's not working
17:59:18 <noah> So, the suggestion that it's an antipattern comes from Robin, and that's in part what led us to discuss today.
17:59:22 <JeniT> marcosc: the thing in github is that when you navigate to the raw file in github, it's served as text/plain
17:59:33 <slightlyoff> FWIW, CSP is only authoritative in a modifier sense; the document is still valid HTML without the CSP restrictions
17:59:42 <Larry> people would fix their servers if browsers rejected mislabeled content
17:59:47 <JeniT> ... if I have a type that I'm working on, there's no way of registering it in github
17:59:56 <slightlyoff> so CSP is strict subsetting, not type changing
18:00:05 <Larry> supporting "nosniff" would be a way of making metadata authoritative
18:00:05 <JeniT> wycats: web reality is that people don't have a lot of control over their deployment environments
18:00:24 <JeniT> marcosc: when I read the finding, the assumption seemed to be that there was a user and someone in control of a server
18:00:43 <JeniT> ... and the most common case now is that you don't run your own server now
18:00:54 <noah> So, all this tends to confirm me feeling that the virtues of Postel's law are way oversold. If we were stricter about what we accepted from the start, we'd have lots more correctly typed content, and the Web would be a much more reliable source of information.
18:01:04 <JeniT> wycats: same with CloudFront
18:01:06 <slightlyoff> q+
18:01:18 <noah> q?
18:01:25 <Larry> i submitted specific bug reports on the sniffing spec
18:01:40 <JeniT> marcosc: my blog is another example, things are getting proxied all over the place, I don't have a lot of control
18:01:56 <noah> ack next
18:02:06 <JeniT> ... I'm not going to be able to influence what that service is doing
18:02:24 <noah> q+ to say it's not only the browsers
18:02:31 <JeniT> wycats: there are some cases where you should care about authoritative metadata and some cases where you shouldn't
18:02:31 <Larry> authoritative metadata needs fixing
18:02:34 <noah> ack next
18:02:38 <JeniT> annevk: the specs capture this but the finding doesn't
18:02:48 <JeniT> slightlyoff: CSP is different than other metadata
18:02:54 <JeniT> ... it's strict subsetting
18:03:00 <Larry> https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=MIME&resolution=---
18:03:02 <annevk> I think CSP might have been a distraction :-(
18:03:19 <annevk> I just mentioned it as something we want to be authoritative
18:03:24 <JeniT> ... removing the CSP metadata from a document might functionally invalidate it, but doesn't otherwise change its interpretation
18:03:49 <JeniT> slightlyoff: it's ignored on browsers that don't support it
18:03:52 <Larry> i think the general principle of metadata might be different for content-type charset
18:03:54 <JeniT> ... it's best effort
18:04:00 <Larry> http://trac.tools.ietf.org/wg/websec/trac/query?component=mime-sniff
18:04:07 <Marcosc> Marcosc has joined #tagmem
18:04:08 <JeniT> annevk: once it's supported in all browsers, you have to use it
18:04:18 <Marcosc> +q
18:04:20 <JeniT> wycats: CSP doesn't give you 100% protection for all users
18:04:37 <JeniT> slightlyoff: it doesn't modify the type of the document or create an alternative processing path
18:04:56 <JeniT> wycats: you can't say "onclick=" in certain CSP modes
18:04:58 <Larry> servers should send no content-type rather than a wrong one
18:05:42 <JeniT> ... if you turn off eval for example, it's application/javascript minus eval
18:05:59 <JeniT> noah: it's not changing the feature list, it's just disallowing some of the features
18:06:19 <JeniT> timbl: you brought this up as somewhere that sniffing is not done
18:06:31 <JeniT> annevk: yes, it's not that authoritative metadata is an incorrect finding
18:06:44 <JeniT> ... we still use it for CSP for example
18:06:52 <JeniT> slightlyoff: it's not authoritative, it's best-effort
18:07:02 <JeniT> wycats: from the perspective of a client, it's not best-effort
18:07:20 <slightlyoff> thanks
18:07:24 <slightlyoff> q-
18:07:27 <JeniT> annevk: another example would be X-Frame-Headers
18:07:35 <noah> ack next
18:07:36 <JeniT> ... places where the metadata *is* authoritative
18:07:37 <Zakim> noah, you wanted to say it's not only the browsers
18:07:45 <JeniT> ... or with CORS, we have to trust the headers
18:07:52 <JeniT> ... not looking into content to see if headers are wrong
18:08:01 <JeniT> noah: I know that this is going to come up again and again
18:08:37 <JeniT> ... over the next few years, we're going to have to discuss server<->browser vs one in which content is served, and browser is an extremely important use case
18:08:50 <wycats__> q+
18:08:58 <JeniT> ... we don't know what's going to be reading this in 20-30 years
18:09:10 <JeniT> slightlyoff: we're still going to be using browsers in 20-30 years
18:09:22 <JeniT> noah: we'll probably be using browsers for a bunch of things we do today
18:09:35 <JeniT> ... but HTTP is usable for many things beyond page browsing by humans
18:09:39 <JeniT> ... like google crawlers
18:10:07 <JeniT> ... in general, HTTP and URIs are important infrastructure
18:10:22 <JeniT> ... it's like saying that the telephone system is only going to be used for telephony
18:10:33 <slightlyoff> googlebot is TRYING to process the world the way users do
18:10:36 <slightlyoff> that's all it doe
18:10:38 <slightlyoff> s
18:10:41 <slightlyoff> that's its job in life
18:10:42 <JeniT> wycats: there's a common ubiquitous user agent, which is a browser
18:10:50 <slightlyoff> q+
18:10:55 <JeniT> noah: that's important, but I want to talk about what servers should do too
18:11:09 <JeniT> timbl: the spec is a contract between client and server
18:11:11 <slightlyoff> noah: googlebot's stated mission in life is to process and "see" the web the way users do
18:11:25 <Larry> windows does x-content-type-options: nosniff, that would let metadata be authoritative
18:11:30 <noah> q?
18:11:47 <Larry> q+ to give pointers to background
18:11:53 <JeniT> ... I wonder whether we should define two webs: a simple one in which authoritative metadata is a platonic ideal
18:11:59 <JeniT> ... it's easy to teach someone how it works
18:12:04 <JeniT> ... in fact there are variations
18:12:08 <JeniT> ... a much larger book
18:12:25 <JeniT> ... for a lot of the web, you can ignore the authoritative metadata issues when you're designing websites
18:12:36 <JeniT> ... maybe it's useful to have both
18:12:37 <slightlyoff> what's the use in a toothless finding?
18:12:44 <JeniT> ... authoritative metadata is a model
18:12:54 <JeniT> ... just as it's useful to have an HTML spec which is "these are the tags"
18:12:57 <wycats__> it's easy to teach people lies
18:12:59 <JeniT> ... maybe we need two documents
18:13:01 <wycats__> people do this all the time
18:13:03 <wycats__> throughout the world
18:13:11 <JeniT> annevk: that question hasn't been answered
18:13:25 <JeniT> ... should we recommend people use mime types for fonts, even though we know that clients will ignore them
18:13:31 <Larry> the MMIME types for fonts are a mess
18:13:44 <slightlyoff> Larry ; sure, but does it matter?
18:13:47 <JeniT> ... there's a mime type for app cache manifests, for example
18:13:53 <slightlyoff> that's the only question that seems to be at issue
18:14:03 <JeniT> ... we could encourage its use and flag it in the console if the wrong mime type is used
18:14:08 <Larry> yes, slightlyoff, the font people tell me they have lots of problems
18:14:24 <JeniT> ... we could indicate in the browser the mismatch
18:14:25 <noah> ack next
18:14:30 <Larry> there are awful workarounds
18:14:41 <JeniT> marcosc: you get console warnings for some mismatches in Chrome
18:14:55 <JeniT> ... I have a JSON-based format, I want it to behave in a particular way
18:14:58 <JeniT> ... what do I do?
18:15:10 <JeniT> ... I need some authoritative metadata there
18:15:30 <JeniT> ... JSON doesn't provide a way of giving a magic number
18:15:42 <JeniT> ... no comments or any other way of including a magic number
18:15:51 <JeniT> ... XML is different because you can use a namespace
18:16:03 <noah> ack next
18:16:13 <noah> ack next
18:16:23 <timbl> q+
18:16:59 <JeniT> slightlyoff: the mission of googlebot is to represent to users through search results what they would have chosen as humans
18:17:14 <JeniT> ... we do everything we can to view the pages as a human would
18:17:37 <JeniT> ... googlebot is necessarily browser-like
18:17:39 <noah>  Yes, Alex, I acknowledged that the Google Bots are focused on matching what would be seen through a browser, at least for now. If Google Bots ever want to help you find linked data, that might change.
18:18:03 <JeniT> ... systems that have to answer questions for humans need to see the web as humans do
18:18:17 <JeniT> ... second point: the question that marcosc raised
18:18:32 <JeniT> ... is the question that you have a processor that doesn't know what to do with it?
18:18:40 <JeniT> marcosc: the pattern now is to invoke it through an API
18:18:53 <JeniT> ... concretely I'm thinking of the Firefox hosted application model
18:19:02 <slightlyoff> noah the bots are trying to help you find linked  data today; see schema.org markup
18:19:07 <JeniT> ... you install by pointing to a JSON file
18:19:20 <slightlyoff> noah but that's just a sub-axis of the human-visible content we already try to make sense of
18:19:24 <JeniT> ... and what should happen if someone gets hold of that URL and pastes it into the location bar
18:19:43 <JeniT> ... the bigger question is that we have these annoying formats that don't allow magic numbers
18:19:51 <JeniT> ... and we need to be able to deal with those as well
18:19:55 <JeniT> noah: yes, and we always will
18:20:24 <slightlyoff>  I can't speak for the crawl team and their interests, but our anti-spam techniques generally boil down to "you can't like to us, show us what you'd show a human", so that's a hard constraint in the real world
18:20:29 <JeniT> wycats: the authoritative metadata finding is being ignored by the most popular user agents
18:20:41 <slightlyoff> s/like/lie/
18:20:48 <JeniT> ... I think we should recognise that there are good reasons for user agents to ignore it
18:20:50 <slightlyoff> agree with wycats__
18:21:02 <Larry> "Authoritative Metadata" tries to accomplish too much-- combining all kinds of metadata. The question si really "cascading metadata"
18:21:07 <JeniT> ... also it's not a good platonic ideal if it doesn't work
18:21:11 <noah> q?
18:21:39 <JeniT> timbl: the point of the platonic ideal is that it's a sketch or a pattern that is easy to understand
18:21:46 <noah> q+ to speculate on changing must to should, and focusing more on servers?
18:21:49 <Larry> sniffing sounds better than labeling, but sniffing can't be made to work, because the ambiguity is INRTRINSIC for polyglot, puns, and intrinsically unreliable.
18:22:02 <JeniT> ... there's the Content-Type model, the FTP model of understanding the file extension, and the magic number world
18:22:19 <JeniT> ... unix pre-Mac used file extensions officially but could sniff things
18:22:29 <JeniT> ... in the early web, people got stuck on the extension
18:22:34 <Larry> if you are going to standardize sniffing, then you might as well put the sniffing in the server rather than the client
18:22:37 <JeniT> ... in the browser, do you look at the suffix?
18:22:41 <JeniT> annevk: very rarely
18:22:52 <JeniT> timbl: when you say "the most common application is the browser"
18:23:07 <JeniT> ... the browser is lots and lots of different clients in different situations
18:23:29 <JeniT> wycats: I can imagine a universe where a platonic ideal spec is useful, but it shouldn't say MUST or MUST NOT
18:23:34 <JeniT> timbl: what about talking about patterns?
18:23:59 <JeniT> wycats: if we write something about Content-Type, we should look at what has actually worked
18:24:15 <JeniT> timbl: if you removed everything about Content-Type in browsers, it wouldn't work
18:24:46 <JeniT> annevk: we can't remove it at this point, HTML and CSS there's nothing you could use (to sniff)
18:24:49 <Larry> q?
18:25:06 <JeniT> wycats: in the user agent, it's very very common not to do it
18:25:18 <Larry> "platonic ideal" is a red herring
18:25:25 <JeniT> ... even recently, with fonts and manifests it hasn't worked
18:25:29 <Larry> Plato has nothing to do with this ideal
18:25:35 <JeniT> timbl: we've got these three patterns
18:25:45 <Larry> s/red herring/incorrect reference/
18:26:06 <JeniT> ... it's not an anti-pattern
18:26:09 <noah> ack next
18:26:10 <Zakim> Larry, you wanted to give pointers to background
18:26:13 <JeniT> annevk: darobin rolled back from saying that
18:26:27 <JeniT> Larry: wishing that you could do sniffing is unrealistic
18:26:39 <JeniT> ... you can't do it between text/plain and anything
18:26:45 <Marcosc> +q
18:26:50 <wycats__> I agree that it's not an anti-pattern, but I disagree that we should try to tell people that it's the one true way to do things
18:26:51 <JeniT> ... magic numbers are used in different places
18:26:59 <wycats__> and the current spec irretrievably says that
18:27:04 <JeniT> ... sniffing is intrinsically heuristic
18:27:11 <JeniT> ... you might as well put the rules in the server
18:27:25 <JeniT> ... the finding covers too many cases
18:27:36 <JeniT> ... there are all sorts of metadata, content type, character sets etc
18:27:42 <JeniT> ... might be better to focus on content type issue
18:27:50 <JeniT> ... sniffing isn't a viable alternative to labelling
18:28:01 <JeniT> ... it's not a matter of authoritative metadata, more cascading metadata
18:28:09 <JeniT> ... different sources of information about what the type would be
18:28:26 <JeniT> ... comments on the web sec, bug reports on the mime sniff living standard
18:28:38 <wycats__> I don't understand how anyone thinks we are going to have a spec that tells the HTML spec that it MUST NOT do something that it has to do to match reality
18:28:40 <wycats__> that's just absurd
18:28:41 <JeniT> ... it's a complicated situation
18:28:51 <JeniT> ... I don't think there'll be a simple solution
18:28:54 <noah> ack next
18:28:59 <Marcosc> -q
18:29:00 <JeniT> ... to rescind it or sniff everywhere
18:29:21 <JeniT> noah: we have the reality we do with servers, I don't think it proves very much about what might have been improved in the beginning
18:29:33 <JeniT> annevk: in the beginning we didn't have Content-Type, we just had sniffing
18:29:35 <slightlyoff> how does this even matter?
18:29:54 <slightlyoff> we can't buy into Postel's law less
18:30:02 <slightlyoff> q+
18:30:04 <Larry> slightlyoff: yes, you can
18:30:07 <Marcosc> +q
18:30:12 <JeniT> noah: this is water under the bridge though
18:30:29 <Larry> x-content-type-options: nosniff  "Solves" the problem
18:30:33 <JeniT> ... it's not really clear how many of the problems are because it's conceptually flawed
18:30:46 <timbl> q+ to say that I much prefer the content-type, body pair model to the one in which all possible document contents are sniffed by one single interplanetary sniffing algorithm.   Robin's proposal,  that we have things like <plaintext> just begs the question, and moves the authoritative metadata moves to the next level.
18:31:04 <JeniT> ... or because it hasn't been implemented
18:31:07 <bkardell_> bkardell_ has joined #tagmem
18:31:14 <JeniT> ... there are architectural reasons why follow-your-nose is important
18:31:16 <wycats__> timbl: I agree with that
18:31:36 <wycats__> timbl: I agree that in theory that is good, but we *must* accept that Postel's Law is the reality of the Internet
18:31:39 <wycats__> why mess with success?
18:31:51 <JeniT> ... it should be possible that as much as possible of the web can be understood by following pointers
18:32:01 <JeniT> ... maybe we can refocus the finding
18:32:01 <slightlyoff> timbl postel's law isn't a "nice to have"; only one half of it is
18:32:11 <slightlyoff> it's a description of what systems at scale INEVITABLY do
18:32:15 <JeniT> ... surely no one thinks serving a PNG as image/jpeg is the right thing to do
18:32:17 <Larry> q+ to talk about recasting the language
18:32:35 <JeniT> ... we don't know what people will do long term
18:32:45 <JeniT> ... labelling things well is generally good practice in an architecture
18:32:49 <timbl> Postell's law is not th reality of HTML5
18:32:57 <wycats__> timbl: sure it is
18:32:57 <slightlyoff> timbl of course it is.
18:33:01 <wycats__> look at the parser?
18:33:08 <slightlyoff> timbl it's *actively* that
18:33:09 <wycats__> every branch that says "This is an Error" tells the parser what to do anyway
18:33:13 <JeniT> annevk: the community doesn't have the tools to follow this
18:33:25 <JeniT> noah: the tools will evolve
18:33:35 <slightlyoff> q?
18:33:39 <JeniT> timbl: we can push the community, CORS for example
18:33:40 <noah> q-
18:33:41 <Larry> The "nosniff" button is deployable
18:33:49 <Larry> s/button/option/
18:34:09 <JeniT> wycats: CORS isn't implemented widely because it requires sysadmin access
18:34:11 <annevk> there's nosniff content out there that you need to sniff
18:34:11 <noah> q?
18:34:22 <JeniT> marcosc: even W3C doesn't do it properly
18:34:25 <annevk> because IE only implemented part of it
18:34:44 <slightlyoff> q?
18:34:47 <JeniT> wycats: we could decide that Postel's law is an interesting curiosity, or an important thing on the internet
18:35:22 <JeniT> timbl: the HTML5 people say that you have to be liberal in what to send and liberal in what to expect
18:35:26 <Larry> annevk "need to" bears closer examination. You mean IE still sniffs "nosniff" content?
18:35:29 <slightlyoff> but that's not true about how behavior works
18:35:35 <JeniT> wycats: the spec says exactly what to do when there are errors
18:35:40 <annevk> Larry: yeah, e.g. image/jpeg vs image/png
18:35:46 <annevk> Larry: cause it all goes down the image decoder
18:35:49 <slightlyoff> q?
18:35:53 <JeniT> noah: we need to push people to be conservative in what they send
18:36:00 <JeniT> ... that's the other side of Postel's law
18:36:16 <JeniT> timbl: in Postel's law there's a huge space of messages that are not sent
18:36:41 <JeniT> ... in HTML5, there is no difference in what you can send and what's accepted
18:36:41 <slightlyoff> q?
18:36:57 <JeniT> wycats: HTML5 there's a set of documents which are valid and others
18:37:08 <JeniT> ... the user agent can fail when there's an error
18:37:10 <noah> q?
18:37:13 <noah> ack next
18:37:33 <JeniT> slightlyoff: if you look at the new parser for webkit, we have error functions which are noops
18:37:37 <noah> zakim, close the queue
18:37:37 <Zakim> ok, noah, the speaker queue is closed
18:37:45 <JeniT> ... in the real-world the software that has to continue to work
18:38:05 <JeniT> ... in Postel's law, there's the motherhood and apple pie of publishers
18:38:20 <JeniT> ... and the practical reality of massive scale with consumers
18:38:28 <Ashok> Ashok has joined #tagmem
18:38:38 <JeniT> timbl: the current situation is that people are liberal in what they produce, and the browsers are liberal in what they accept
18:38:55 <noah> q?
18:38:58 <JeniT> ... that's why I said that Postel's law does not describe the current web
18:38:59 <wycats__> 1+
18:39:00 <wycats__> q+
18:39:06 <JeniT> annevk: the guidelines are conservative/liberal
18:39:15 <slightlyoff> we saw this even in RSS
18:39:20 <noah> ack next
18:39:26 <wycats__> the whole point of Postel's Law is that the reality is liberal/liberal
18:39:34 <annevk> aaah
18:39:42 <JeniT> marcosc: maybe what darobin means to say is to rethink what it means to be conservative on the server end
18:39:43 <wycats__> it's telling people to be conservative, but if people LISTENED you wouldn't need the other half
18:39:48 <slightlyoff> timbl even in formats where errors should have been "fatal", we ended up with Postel's law dominating, and we got fixup-based parsers for those formats too
18:39:50 <annevk> hehe
18:39:51 <JeniT> ... it can be sending content type or magic number or something else
18:40:02 <JeniT> noah: it says follow the specs
18:40:26 <JeniT> marcosc: we've been having discussion about magic numbers over last two years or so, for example with app cache and fonts
18:40:32 <noah> That can't be the point of it. Postels law says be conservative when sending. I accept that being liberal is where we've landed, but that is surely NOT what Postel intended.
18:40:36 <JeniT> ... people just couldn't use content-type, maybe there we can use magic numbers
18:40:45 <JeniT> ... I'm saying there's other ways of being conservative
18:40:48 <slightlyoff> why are we debating something that can't work in practice?
18:40:49 <wycats__> the point of Postel's law is that reality is always people sending liberally
18:40:51 <JeniT> timbl: conservative means sticking to the spec
18:40:54 <slightlyoff> i htought  we cared about the architecture of the WEB
18:40:55 <wycats__> otherwise you can nuke the liberal half
18:41:00 <noah> What I think he wanted was to give receivers a little wiggle room to keep running while everyone cleaned things up, not to license long term nonconformance.
18:41:00 <slightlyoff> not a system that's web-like but not the web?
18:41:03 <JeniT> ... all the groups are defining the protocol about how the web works
18:41:04 <noah> q?
18:41:07 <noah> ack next
18:41:08 <Zakim> timbl, you wanted to say that I much prefer the content-type, body pair model to the one in which all possible document contents are sniffed by one single interplanetary sniffing
18:41:08 <Zakim> ... algorithm.   Robin's proposal,  that we have things like <plaintext> just begs the question, and moves the authoritative metadata moves to the next level.
18:41:09 <wycats__> noah: definitely not
18:41:22 <JeniT> ... I'd like to see the spec so that when I'm writing a server from scratch I know what to do, and one that isn't too complicated
18:41:37 <JeniT> marcosc: it's a real problem for me that I don't know how to label my new JSON format
18:41:43 <JeniT> timbl: label it
18:42:06 <JeniT> marcosc: I need to know whether to use a magic number or a mime type in a new binary format
18:42:11 <JeniT> ... why should I bother if the browser doesn't care
18:42:12 <Yves> 
18:42:18 <JeniT> annevk: the browser cares if you say it should care
18:42:37 <JeniT> wycats: what matters to me is documenting reality
18:42:37 <noah> ack next
18:42:38 <Zakim> Larry, you wanted to talk about recasting the language
18:43:00 <JeniT> Larry: it's helpful to stop talking about should I ever serve X as Y
18:43:11 <JeniT> ... you have a body and a header and try to figure out how to interpret it
18:43:18 <JeniT> ... it can be ambiguous about what it is
18:43:39 <JeniT> ... it's possible to add the no sniffing option, but the browsers have to make it work
18:43:57 <JeniT> ... once someone starts sniffing in a no-sniff context, everyone will stop doing it
18:44:09 <JeniT> ... it has to be linked to an event, for example introduction of HTTP 2.0
18:44:22 <JeniT> ... put the sniffer in the proxy, so you could serve it as no-sniff
18:44:28 <JeniT> ... that would reduce a lot of the ambiguity
18:44:36 <annevk> That'll hurt adoption of HTTP 2.0
18:44:40 <annevk> You don't want to close couple that
18:44:40 <JeniT> ... absolutely true that if no one enforces it then content providers won't fix the content
18:44:41 <wycats__> does anyone disagree with removing the MUST?
18:44:47 <noah> zakim, reopen the queue
18:44:47 <Zakim> ok, noah, the speaker queue is open
18:44:49 <wycats__> q+
18:44:58 <slightlyoff> wycats__ I do not disagree with that
18:45:03 <JeniT> noah: we need to decide whether to take this beyond this discussion
18:45:12 <JeniT> ... I don't think there's even a core of an emerging consensus
18:45:28 <JeniT> ... it's possible that we should send people off to frame something that they think might lead to TAG consensus
18:45:34 <JeniT> ... next thing up is setting TAG priorities
18:45:48 <slightlyoff> I'd like to propose that we not try to advise for things that are fundamentally incompatible with observable reality
18:45:52 <JeniT> ... is this something that people want to put time and energy to?
18:45:55 <annevk> q+
18:46:18 <slightlyoff> I feel strongly that this cuts to the core of TAG credibility
18:46:30 <slightlyoff> and our current deficit in this regard.
18:46:32 <JeniT> wycats: I think the consensus that might be here that the TAG shouldn't have MUSTs when WGs can't implement those MUSTs
18:46:52 <Larry> if you're going to do something about sniffing, then work on the sniffing spec
18:47:00 <slightlyoff> I agree with rescinding it
18:47:07 <Larry> http://mimesniff.spec.whatwg.org/
18:47:15 <JeniT> timbl: we could add a disclaimer in it
18:47:17 <Larry> i think rescending it without replacing it is irresponsible
18:47:21 <slightlyoff> Larry that's one potential option; we can also explore others
18:47:29 <slightlyoff> Larry in what sense?
18:47:40 <JeniT> ... sounds like HTML5 spec doesn't describe how browsers do all interpretation?
18:47:47 <JeniT> annevk: not quite everything, but it's fairly complete
18:47:49 <slightlyoff> what new space for error does it open that is currently not being explored?
18:48:07 <JeniT> timbl: we could say "this is the model", but see HTML5 for what actually happens in the browser
18:48:30 <JeniT> wycats: right now, there's a big list of things not to do, and I'd like to rescind that
18:48:34 <Larry> there's a question. we had an answer. if that answer is wrong, then what's the right answer
18:48:56 <JeniT> noah: we can't settle this here and now, I want to get two people to gather proposed solutions
18:49:06 <JeniT> ... lead email & telcon discussion of pros and cons
18:49:08 <Zakim> -Masinter
18:49:26 <slightlyoff> didn't we just have that discussion?
18:49:46 <JeniT> ... or we could discuss again on Wed
18:49:58 <JeniT> ... get us to a place where we can do something useful
18:50:07 <JeniT> timbl: we're not all on the same page at the moment
18:50:17 <JeniT> ... let's see if we can pursue on Wed
18:50:53 <JeniT> marcosc: could we have a breakout on Wed with a couple of us?
18:50:59 <JeniT> noah: do that at another time
18:51:07 <slightlyoff> +1 to that
18:51:17 <JeniT> wycats: my proposal is rescind current document & replace with something aspirational
18:51:28 <Marcosc> MC: +1
18:51:31 <slightlyoff> agree
18:51:32 <slightlyoff> +1
18:51:36 <JeniT> ... the current document doesn't reflect reality at all, so it's bad to leave it around
18:51:46 <JeniT> noah: let's pick it up Wed
18:51:57 <JeniT> ... I'd like a couple of people who could frame the discussion in that way
18:51:57 <annevk> It could be like CSS1: http://www.w3.org/TR/CSS1/
18:52:40 <JeniT> timbl: I went through IETF and learned to be good about MUSTs and MAYs
18:52:47 <JeniT> ... they've often tripped us up
18:53:07 <JeniT> ... the IETF says you must use the word MUST when conforming specs must do it
18:53:15 <JeniT> ... people read it as an ethical must
18:53:18 <JeniT> ... which it isn't
18:54:02 <JeniT> ... it just indicates that it's not a conforming implementation of the spec if it doesn't follow those
18:54:14 <JeniT> wycats: that means that browsers aren't conforming implementations
18:54:46 <JeniT> Topic: TAG Orientation & scheduling F2F
19:07:24 <slightlyoff> point of order: can we get a Google Calendar or something for our calls and agendas?
19:12:23 <bkardell_> bkardell_ has joined #tagmem
19:16:49 <JeniT> noah: in this session I want to do three things: 1. set out goals for the meeting as a whole, 2. say a few things as chair, 3. schedule F2F
19:16:51 <wycats__> slightlyoff: yes please
19:17:08 <JeniT> ... main goals:
19:17:21 <JeniT> ... look at what we want to do in next 1-2 years
19:17:32 <JeniT> ... need to wrap up some of the existing work
19:17:42 <JeniT> ... and figure out what we're doing, not just picking up random projects
19:17:54 <JeniT> ... when in gear, we'll usually have 2-3 major projects
19:18:03 <JeniT> ... with 2-3 people driving each effort
19:18:14 <JeniT> ... want to work out which of the things we're talking about are likely to be these things
19:18:28 <JeniT> ... next, want to establish shared understanding & working relationships
19:18:42 <JeniT> ... next, want to pick the 2-3 things that we want to try
19:18:50 <JeniT> ... not just random discussion, things that people are going to take forward
19:19:00 <JeniT> ... with writing, telcons, bringing in community
19:19:13 <JeniT> ... next, starting to review establish TAG positions that are controversial
19:19:20 <JeniT> ... next agree to publish fragids
19:19:35 <JeniT> ... next, decide directions on existing projects
19:19:47 <JeniT> ... there are a few big ones (publishing & linking, httpRange-14)
19:20:00 <JeniT> ... and a bunch of things that are more minor, many that are stale issues
19:20:22 <JeniT> ... might look at them on Wed
19:20:33 <JeniT> annevk: can anyone sift through them?
19:20:40 <JeniT> noah: I'd like to but I have very limited time
19:21:14 <JeniT> ... ---
19:21:25 <JeniT> ... welcome new members, and thank you to outgoing members
19:21:41 <JeniT> ... outgoing members should always feel welcome to come to meetings & social events
19:21:52 <JeniT> ... this morning we looked at the charter & the mission statement
19:21:57 <JeniT> ... that's the bounds of what to do
19:22:05 <JeniT> ... my job is to organise the group and make sure we get results
19:22:09 <JeniT> ... we're a small WG
19:22:15 <JeniT> ... most others have people who are sent to solve a problem
19:22:35 <JeniT> ... would like everyone to think about commitments you've made
19:22:48 <JeniT> ... you signed up to about 25% of your time, and to come to F2F meetings
19:22:54 <JeniT> ... there's no one to do the work but us
19:23:05 <JeniT> ... we are very understanding about peoples' day jobs
19:23:13 <JeniT> ... bursts of activity for 3-4 months
19:23:34 <JeniT> ... but this stuff is hard, and people disagree about it, and it needs effort
19:23:55 <JeniT> ... we have to impose people to do grunt stuff too
19:24:06 <JeniT> ... including getting CVS sorted out, and scribing
19:24:23 <JeniT> ... trying to be open to requests around topics
19:24:54 <JeniT> ... but administrative changes are difficult
19:25:44 <JeniT> ... try to try things the way we're doing it now
19:25:50 <JeniT> ... hold of critiques for 3-6 months
19:26:05 <JeniT> ... because it's hard for me
19:26:26 <JeniT> ... on scribing: we try to be careful about privacy
19:27:05 <JeniT> ... historically this is a close group, not unusual to hang out
19:27:23 <JeniT> ... a lot gets sorted out over dinner etc
19:27:40 <JeniT> ... project pages
19:28:40 <JeniT> ... when we kick off a project, we try to create a project page that covers goals, success criteria, deliverables, people, issues/actions etc
19:28:56 <JeniT> ... all drafts & pages like this should have a 'current version' and dated versions
19:29:04 <JeniT> ... minutes refer to dated versions
19:29:30 <JeniT> Topic: F2F Scheduling
19:29:52 <JeniT> noah: try to meet when Tim can be there, and me
19:30:00 <JeniT> ... propose London meeting late May
19:30:49 <JeniT> ... week of 27th
19:31:43 <JeniT> wycats: it's not trivial for me to schedule international travel with only a couple of months notice
19:32:09 <JeniT> ... best 12 months out
19:32:26 <JeniT> timbl: sometimes urgent things come up
19:32:42 <JeniT> noah: we'll typically do 4-6 months
19:33:05 <JeniT> ... so would pencil in September now too
19:33:37 <slightlyoff> what were the dates again?
19:33:44 <JeniT> ... is there anyone who can't make 28-30th May
19:33:47 <slightlyoff> can do both
19:33:53 <JeniT> ... anyone who can't make 29-31st?
19:34:03 <JeniT> ... anyone prefers 28-30th?
19:34:11 <JeniT> ... most prefer 29-31st
19:34:34 <slightlyoff> that works, thanks so much
19:34:48 <JeniT> RESOLVED: TAG will meet in London 29th-31st
19:35:04 <JeniT> s/29th-31st/29th-31st May/
19:36:13 <slightlyoff> there's also Google space, but would take time to confirm
19:39:04 <slightlyoff> what dates are we talking about now?
19:39:34 <slightlyoff> thanks
19:39:43 <timbl> ht?
19:40:23 <timbl> Henry?
19:42:15 <bkardell_> bkardell_ has joined #tagmem
19:43:09 <slightlyoff> can do
19:48:12 <slightlyoff> what dates?
19:48:15 <slightlyoff> can't hear on the phone
19:48:36 <slightlyoff> of Dec?
19:48:42 <slightlyoff> halp ;-)
19:49:45 <slightlyoff> thanks
19:49:47 <annevk> jan 6 - jan 10 2014
19:49:58 <slightlyoff> SGTM
19:50:20 <slightlyoff> yep, sounds good
19:50:25 <slightlyoff> can do those dates
19:51:47 <jar> jar has joined #tagmem
19:51:57 <slightlyoff> count on me being in CA
19:53:42 <JeniT> annevk: what happens between May & October?
19:54:39 <JeniT> noah: there's lots of holiday, but we'll have telcons
19:54:56 <JeniT> for minutes: booked Oct 13-15th
19:55:01 <JeniT> booked Jan 6-10th
19:55:13 <JeniT> Topic: Coordination with ECMA TC39
19:55:23 <JeniT> http://www.w3.org/2001/tag/2013/03/18-agenda#ECMATC39
19:55:56 <JeniT> wycats: slightlyoff & I are both on TC39
19:56:10 <JeniT> ... there are many things TC39 are doing to enhance JS semantics to provide more things that you could do with it
19:56:18 <JeniT> ... there are 2 things I'd like W3C to do be doing
19:56:26 <JeniT> ... 1. taking advantage of these better semantics
19:56:38 <JeniT> ... eg defining getters & setters, proxies, modules
19:56:41 <Zakim> +Masinter
19:56:47 <Marcosc> +q
19:56:50 <JeniT> ... W3C WGs should describe things in terms of TC39 JS
19:57:01 <JeniT> ... less around ad-hoc ideas around host objects
19:57:14 <JeniT> ... Chapter 8 in JS says user agents can do anything they want
19:57:29 <JeniT> ... I'd like it if WGs would take advantage of new power of non-Chapter 8 parts of JS
19:57:43 <JeniT> ... 2. there are things that TC39 that are in conflict with what's happened in W3C
19:57:49 <JeniT> ... in particular around definition of web workers
19:57:50 <annevk> q-
19:58:00 <JeniT> ... which is around adhoc definition of global object
19:58:24 <JeniT> ... want to advise WGs to start thinking, to the extent that there are new semantics
19:58:36 <JeniT> ... right now new browser APIs there are new objects on global object
19:58:44 <JeniT> ... but there will be modules
19:58:52 <JeniT> timbl: are these like modules in node?
19:59:10 <JeniT> wycats: the syntax indicates imports etc without executing the code
19:59:19 <JeniT> timbl: it looks procedural but is declarative?
19:59:25 <JeniT> wycats: it's like an import
19:59:31 <JeniT> ... import variable from module
19:59:39 <noah> q?
19:59:45 <JeniT> ... module name is a string
19:59:45 <JeniT> timbl: there's a search path?
19:59:47 <noah> ack wycats__
19:59:53 <JeniT> wycats: there's a series of steps
20:00:06 <JeniT> ... each has built-in descriptions and hooks
20:00:07 <Marcosc> this one
20:00:11 <noah> Ah, OK, thanks.
20:00:11 <JeniT> annevk: and it's all async?
20:00:20 <slightlyoff> yes, it's all async
20:00:21 <JeniT> wycats: yes
20:00:52 <JeniT> ... W3C isn't paying a ton of attention to this
20:01:02 <JeniT> ... it would be great if new APIs from W3C were defined in a module
20:01:09 <JeniT> ... there's a lot of detail here
20:01:23 <JeniT> ... slightlyoff & I would volunteer to detail these
20:01:25 <noah> q+ to ask about balance between TAG and other wgs?
20:01:33 <JeniT> ... we'd like to have general direction to use these
20:01:39 <JeniT> timbl: needs to work in either situation
20:01:56 <noah> q+ jar
20:01:57 <JeniT> wycats: could just stick with global objects, but I think that would be a mistake
20:01:57 <slightlyoff> q+
20:02:15 <JeniT> marcosc: host objects aren't defined in terms of ES6
20:02:22 <slightlyoff> this is a bug
20:02:25 <slightlyoff> webidl is a bug
20:02:27 <JeniT> ... you're talking about layering on top of ES6
20:02:44 <JeniT> ... we want to adjust WebIDL to use ES6 and define in WebIDL
20:02:58 <JeniT> wycats: there isn't anything in host objects which is incompatible in ES6
20:03:08 <timbl> q+ to ask whether webIDL is right for close Ecmascript integration
20:03:10 <JeniT> ... in ES5 there are host objects, they don't exist in ES6
20:04:06 <JeniT> ... there may well be obscure edge cases where you can't describe things in JS, but in general that's not the case
20:04:10 <noah> q?
20:04:19 <JeniT> marcosc: we had modules in WebIDL we could translate into modules in ES6
20:04:21 <slightlyoff> q?
20:04:36 <noah> ack next
20:04:39 <JeniT> ... we had something where when you declare an object in WebIDL it ends up in global scope
20:04:46 <JeniT> ... I don't think we're fundamentally breaking things
20:04:53 <JeniT> ... I think your proposal is good, that we should align more
20:05:18 <JeniT> annevk: WGs and individuals aren't paying attention
20:05:25 <JeniT> marcosc: ES6 is in flux
20:05:41 <JeniT> ... WebIDL had native brand to get at what the object type is
20:05:45 <JeniT> ... that changed, the name of it changed
20:05:54 <annevk> (I'm paying some attention, but es-discuss is hard to follow and the drafts are PDFs with some force download flag...)
20:05:59 <JeniT> wycats: that's fair, I'm not saying rewrite everything right now in terms of ES6
20:06:11 <JeniT> ... my point is we should start paying attention to it
20:06:22 <JeniT> marcosc: what can we do?
20:06:40 <noah> ack next
20:06:41 <Zakim> noah, you wanted to ask about balance between TAG and other wgs?
20:06:46 <JeniT> wycats: create guidance to WGs about how to think about this, in coordination with TC39
20:07:13 <JeniT> noah: how much of this is the TAG's job and how much is other WG's?
20:07:31 <slightlyoff> I do think they're screwing up big time
20:07:32 <JeniT> ... try to defer to WGs when they exist & have responsibility unless they're screwing up architecturally
20:07:38 <JeniT> ... why here & not Web Apps?
20:07:52 <JeniT> wycats: this is interoperability, working with other standards orgs
20:08:01 <JeniT> marcosc: we have public script coord mailing list
20:08:12 <JeniT> noah: just because we facilitate these things doesn't mean we own them
20:08:30 <JeniT> ... we could still go to Web Apps and ask them to handle it
20:08:40 <JeniT> annevk: I think we could do this through Web Apps
20:08:53 <JeniT> ... there's a ton of WGs but they listen to Web Apps
20:09:13 <JeniT> noah: they could also publish a Rec
20:09:19 <Marcosc> +q
20:09:26 <JeniT> annevk: we're chartered for that, and they're not
20:09:37 <JeniT> noah: APIs are generally in the Web Apps charter, aren't they?
20:09:39 <JeniT> annevk: no
20:09:42 <slightlyoff> q?
20:09:50 <annevk> well APIs are
20:09:50 <JeniT> noah: should we schedule a tutorial on what's new in JS?
20:10:00 <Larry> https://speakerdeck.com/kitcambridge/es-6-the-refined-parts
20:10:06 <annevk> RECs on how to do APIs... dunno
20:10:06 <JeniT> timbl: I bet a bunch of W3Cers would be interested in that too
20:10:10 <annevk> could be I guess
20:10:23 <JeniT> noah: wycats, can you do it low notice? Wed?
20:10:25 <Larry> there was a video talk at W3CConf that was good
20:10:33 <Larry> Kit Cambridge ...
20:10:41 <JeniT> wycats: I could cover a lot of ground on Wed
20:11:01 <JeniT> Larry: there's a good video by Kit Cambridge on ES6
20:11:06 <Yves> top
20:11:10 <Yves> s/top//
20:11:12 <timbl> timbl: It would be good then to sync with Amy who organizes project reviews
20:11:21 <Larry> http://www.w3.org/conf/2013sf/video.html
20:11:28 <Larry> has the video
20:11:40 <slightlyoff> q?
20:11:43 <Marcosc> this is good too: https://dl.dropbox.com/u/3531958/es6-favorite-parts/index.html#/
20:12:40 <JeniT> noah: let's schedule 90 mins on Wed
20:12:43 <JeniT> ... advertise that
20:12:47 <slightlyoff> q?
20:12:58 <Marcosc> -q
20:13:02 <noah> ack next
20:13:09 <jar> http://lists.w3.org/Archives/Public/www-tag/2012Sep/0031.html
20:13:17 <JeniT> jar: sounds like you're talking about same thing as Doug was complaining about
20:13:34 <slightlyoff> inaudible
20:13:45 <JeniT> ... Doug sounded very frustrated
20:13:55 <JeniT> wycats: this is a targeted concern
20:14:05 <JeniT> ... this is WebIDL doing something causing problems with TC39
20:14:22 <JeniT> annevk: XHR is defined as an object, exposed on window, not on prototype window
20:14:39 <JeniT> wycats: as far as TC39 is concerned, there is no prototype window
20:15:01 <JeniT> annevk: are you concerned about people defining things like methods on window or objects?
20:15:19 <JeniT> wycats: you avoid exposing things on window is that you have objects via module import
20:15:22 <slightlyoff> but you WILL have modules
20:15:33 <JeniT> annevk: how do you avoid doing what we do?
20:15:43 <JeniT> wycats: we fake it
20:15:50 <JeniT> marcosc: how stable is the modules proposal?
20:16:02 <JeniT> wycats: I'm not saying start doing modules right now, but that they start looking at it
20:16:06 <JeniT> ... the syntax isn't stable
20:16:14 <annevk> slightlyoff: I'm not saying that, I'm saying that nobody is telling us what to do
20:16:15 <JeniT> timbl: how do serious websites deal with the transition?
20:16:41 <JeniT> wycats: there'll be those that rely on browsers that have modules, and those that don't
20:16:45 <annevk> slightlyoff: this is the first time I heard about this and maybe a bit from the TC39 echo chamber, but that never reaches us in clear terms :/
20:16:50 <JeniT> timbl: will people write things twice, or will they fake it?
20:16:51 <slightlyoff> transpilers
20:17:04 <noah> q?
20:17:08 <noah> q?
20:17:11 <JeniT> wycats: once module syntax is stabilised, they'll stop writing them node style, and start writing them module style
20:17:15 <JeniT> ... using AMD semantics
20:17:31 <JeniT> ... write nice declarative form in syntax
20:17:46 <slightlyoff> FWIW, we already have ES6-to-ES5 transpilers written in JS
20:17:51 <noah> ack next
20:17:55 <JeniT> noah: server-side adaptation for those browsers?
20:18:02 <JeniT> wycats: yes, that's already happening
20:18:14 <JeniT> slightlyoff: ECMAScript compiler in the browser
20:18:17 <JeniT> ... already happening
20:18:30 <Marcosc> s/compiler/transpiler
20:18:32 <noah> I think that was specifically an ECMAScript 6 -> ECMAScript 5 compiler
20:18:42 <JeniT> ... larger point is that WebIDL is today a barrier
20:18:47 <JeniT> ... core mismatches in the types
20:18:47 <noah> s/compiler/transpiler/
20:19:15 <JeniT> ... we should be educating people about new features
20:19:27 <JeniT> ... put people in mindset of users when designing APIs in the first place
20:19:40 <JeniT> ... webIDL doesn't help make it easy for users
20:19:54 <JeniT> ... eg constructible objects with no constructors
20:20:16 <JeniT> ... you can't get an instance of this type
20:20:23 <JeniT> ... it will hand you alien objects you have no recourse for
20:20:34 <JeniT> ... makes you think about types that aren't efficient to express in JS
20:20:39 <JeniT> ... eg numbers that aren't floats
20:20:47 <JeniT> ... leads you towards designs that aren't appropriate
20:21:04 <JeniT> ... at Google, we work through example code ignoring formal description
20:21:05 <Larry> need JSON schemas
20:21:08 <JeniT> ... make that idiomatic
20:21:16 <JeniT> ... work that back to its definition
20:21:32 <JeniT> ... we could help people write idiomatic APIs
20:21:35 <Larry> JSON isn't javascript
20:21:37 <JeniT> q?
20:21:47 <JeniT> ack timbl
20:21:47 <Zakim> timbl, you wanted to ask whether webIDL is right for close Ecmascript integration
20:22:01 <JeniT> timbl: how JS-specific is WebIDL now?
20:22:13 <JeniT> ... is it being enhanced with all the new things in JS?
20:22:17 <JeniT> ... or is it language independent
20:22:32 <JeniT> marcosc: there's like attribute foo, it forces you to create a setter function
20:22:41 <JeniT> annevk: OMGIDL was language independent
20:22:45 <noah2> noah2 has joined #tagmem
20:22:51 <noah2> I guess I'm noah2 now
20:22:52 <JeniT> ... but didn't define a whole bunch of cases, didn't do constructors and stuff
20:23:08 <noah2> q?
20:23:24 <JeniT> timbl: can you use all the tricks in JS in WebIDL
20:23:36 <slightlyoff> we were successful in pulling WebIDL away from Java
20:23:40 <slightlyoff> which it used to be joined at the hip to
20:23:48 <slightlyoff> and there are left-over semantics from that era
20:23:53 <annevk> that's such a non-issue though
20:23:57 <slightlyoff> the mismatch is pretty large still
20:23:59 <annevk> that was basically heycam's hobby thing
20:24:03 <JeniT> wycats: in ES there's internal spec facilities
20:24:05 <annevk> it didn't affect anything
20:24:09 <JeniT> ... which you can overwrite
20:24:17 <slightlyoff> annevk the legacy is driven all the way through the design
20:24:18 <JeniT> ... webIDL makes extensive use of these facilities
20:24:34 <slightlyoff> annevk it did, it introduced types that were JS native
20:24:35 <JeniT> ... want them to use the proper facilities in ES6
20:24:36 <annevk> slightlyoff well yes the legacy is, there are dozens of specs and UAs written in terms of it
20:25:00 <JeniT> ... if we want to have a system that describes what JS objects are doing, we should describe them as something that a JS developer could write
20:25:09 <JeniT> slightlyoff: WebIDL drags you away from idiomatic JS
20:25:18 <JeniT> ... doesn't teach you about how to design a JS API
20:25:32 <JeniT> annevk: until you have an alternative that works for spec writers, don't criticise WebIDL
20:25:59 <JeniT> slightlyoff: the advice is to design the API by example in JS
20:26:07 <JeniT> wycats: this is an important distinction
20:26:18 <JeniT> ... currently it maps onto C++ implementation
20:26:21 <JeniT> ... like int32s
20:26:28 <slightlyoff> it's not simple
20:26:38 <JeniT> timbl: I'm worried the flip side
20:26:49 <JeniT> ... how would it do describing jQuery?
20:26:55 <JeniT> ... with lots of overloading
20:27:03 <JeniT> marcosc: there's no problem with overloading
20:27:14 <JeniT> wycats: WebIDL is mapping onto low level semantics of implementation
20:27:26 <JeniT> ... we want the spec device to map onto semantics of JS not C++
20:27:51 <JeniT> annevk: there's no disagreement
20:28:08 <JeniT> ... there's just not enough people to write the specs
20:28:28 <JeniT> wycats: so we should make WebIDL better to use
20:28:35 <slightlyoff> Marcosc I'm afraid that's just wrong
20:28:36 <JeniT> marcosc: there's different things
20:29:04 <JeniT> wycats: it's meaningless to define something in WebIDL that can't be implemented in JS
20:29:12 <JeniT> annevk: you might want additional constraints
20:30:23 <slightlyoff> annevk wanting additonal constraints are the sort of thing that you should be considering without syntax
20:30:31 <JeniT> noah: history is from a corba-like view of the world, language-independent spec of APIs
20:30:35 <Zakim> -Alex
20:30:41 <JeniT> ... JS emerges as major implementation
20:30:57 <JeniT> wycats: no one wants language independence
20:31:01 <Zakim> +Alex
20:31:11 <JeniT> noah: are we aiming for no WebIDL and just some JS-based spec?
20:31:37 <JeniT> annevk: WebIDL is a mapping
20:32:23 <JeniT> wycats: we're just proposing that if there's something like WebIDL, it should be described in terms of JS
20:32:40 <JeniT> slightlyoff: people who are not JS developers don't have a good guide about how to design JS APIs
20:32:53 <JeniT> ... if you're used to C++ then you reach for WebIDL and use it
20:33:21 <JeniT> ... and you get people building APIs that aren't suited for JS
20:33:30 <JeniT> ... we could change WebIDL, or how we teach people to use it
20:33:36 <Larry> q+ to ask about WebIDL & JSON schemas
20:33:52 <JeniT> ... but let's talk about TypeScript or other options
20:34:19 <slightlyoff> yes, that's right...it's about how to think about the problem
20:34:20 <JeniT> timbl: sounds like it's the way of thinking issue that is the real problem
20:34:37 <JeniT> ... the jQuery pattern of overloading, things like passing around functions
20:34:42 <JeniT> ... these aren't like C++ at all
20:34:43 <noah2> q?
20:34:46 <Larry> news from last week: IETF is spinning up a JSON working group
20:34:55 <slightlyoff> yes, we loose a lot of that sort of flexibility in DOM APIs
20:34:56 <JeniT> ... is there a lot of lossage at the more functional, JS end of the scale
20:35:08 <JeniT> wycats: if you're a C++ programmer, you won't be writing idiomatic JS
20:35:11 <Larry> IETF is doing other JSON work. Including schema for JSON
20:35:14 <noah2> ack next
20:35:15 <Zakim> Larry, you wanted to ask about WebIDL & JSON schemas
20:35:30 <slightlyoff> yes, there's a culture of failure around this
20:35:33 <JeniT> annevk: people are copy&pasting the patterns from previous specs
20:35:51 <JeniT> Larry: IETF are working on JSON, maybe a schema language
20:36:01 <JeniT> ... DP70, talking about when to use XML
20:36:12 <JeniT> ... think it should be extended to talk about XML & JSON
20:36:31 <JeniT> ... bringing this up because JSON schema talks about defining value types
20:36:34 <noah2> http://tools.ietf.org/html//bcp70
20:36:40 <JeniT> ... seem to have a relationship with webIDL
20:36:55 <JeniT> ... if talking to TC39, consider role of JSON
20:37:05 <JeniT> ... it's language independent
20:37:11 <JeniT> annevk: it doesn't have methods
20:37:14 <JeniT> wycats: seems unrelated
20:37:25 <JeniT> timbl: if you define a method, you give types of parameters
20:37:37 <JeniT> ... if you have a complex structured parameter, such as a dictionary
20:37:49 <JeniT> ... or a list whose values are of a particular type
20:38:04 <JeniT> ... then quite a lot of the work in defining the interface to the method is defining the complex parameter
20:38:12 <JeniT> ... and describing that is the same as a JSON schema problem
20:38:27 <JeniT> Larry: the datatypes that are available in WebIDL are basically those available in JSON schema
20:38:35 <JeniT> timbl: can you say that in WebIDL
20:38:47 <JeniT> wycats: yes, WebIDL's problem is not lack of expressive power
20:38:52 <JeniT> ... they just create crazy JS semantics
20:39:12 <JeniT> Larry: my point is under general topic of coordination with TC39, you've identified one issue, about WebIDL
20:39:21 <JeniT> ... while you're thinking about that, interaction with JSON is also important
20:39:27 <Marcosc> Marcosc has joined #tagmem
20:39:38 <JeniT> ... tried to get them to update charter to include coordination with TC39 & WHATWG & W3C
20:39:46 <JeniT> ... W3C needs to be engaged in JSON update also
20:39:48 <noah2> q?
20:40:19 <JeniT> wycats: if it's only a problem with finding people to write a strawman, we can work with that
20:40:33 <slightlyoff> well, I am doing that
20:40:33 <JeniT> annevk: TC39 need to give guidelines to the people doing DOM stuff
20:40:39 <slightlyoff> on a weekly bais to API authors here
20:40:44 <JeniT> ... there's just a lack of communication and lack of guidelines
20:40:49 <JeniT> ... feels more like a shouting match
20:40:53 <slightlyoff> right, nobody's assuming malice
20:40:59 <JeniT> ... we're just trying to solve a problem, and we're input constrained
20:41:09 <JeniT> ... all we get is "you're doing it wrong" with no concrete alternative
20:41:37 <JeniT> wycats: sounds like slightlyoff & I need to go back to TC39 to get communication working better
20:42:09 <JeniT> noah: what would you like the TAG to support you to do?
20:42:09 <slightlyoff> q+
20:42:32 <JeniT> wycats: I'd like to go back to TC39 to get resource on working on successor to WebIDL
20:42:44 <JeniT> noah: I don't know if we have a group to do something with it
20:43:10 <Larry> script-coord mailing list is still active
20:43:35 <noah2> JT: When I did the work on the task force of the HTML and Data stuff, it worked pretty well. So, maybe we say there should be a task force.
20:43:50 <noah2> q?
20:44:02 <noah2> ack next
20:44:30 <JeniT> slightlyoff: I've spent a lot of time working with people who are trying to come up with APIs which are better
20:44:44 <JeniT> ... people don't have experience, haven't got a guide about how to build an idiomatic DOM API
20:45:00 <JeniT> ... we could create those guidelines, talk to TC39 about it
20:45:17 <JeniT> wycats: I like Jeni's proposal to put together a small, focused task force
20:46:06 <JeniT> noah: when we did that, we had a better understanding of what the issues were, as the TAG
20:46:08 <Zakim> -Masinter
20:46:20 <JeniT> ... if we could float these ideas on the TAG mailing list and other lists
20:46:41 <JeniT> ... say that we're considering task force or outreach to TC39
20:47:02 <JeniT> ... see what pushback we get
20:47:19 <JeniT> annevk: Mozilla has invested effort in transitioning from old bindings to WebIDL bindings
20:47:27 <slightlyoff> we have a bunch of perl scripts ;-)
20:47:35 <JeniT> ... the right things happen
20:48:02 <JeniT> wycats: that means there's a constraint to be compatible with that tooling
20:48:24 <JeniT> annevk: API specs are built around ReSpec which has native support for WebIDL
20:48:44 <slightlyoff> I'd once again like to suggest that we can help people design better APIs without changing the tooling; we can push on both
20:48:45 <JeniT> noah: are you saying we should therefore go slow?
20:48:57 <slightlyoff> and they can happen in parallel
20:49:04 <JeniT> annevk: short-term, having better advice would be awesome, especially backed by TC39
20:49:21 <JeniT> ... then we can see whether people disagree
20:49:38 <JeniT> noah: how does TC39 work? how would we engage with them?
20:49:52 <JeniT> wycats: most of the work that gets done is done by champions
20:50:31 <JeniT> ... committee is 20-25 people, once every 2 months F2F meeting
20:50:38 <JeniT> ... chair but he's not like you (noah)
20:50:50 <JeniT> noah: should we get onto their agenda for a meeting?
20:51:10 <JeniT> wycats: slightlyoff or I would become champions within the group
20:51:32 <JeniT> noah: I'm nervous that we're just starting on this, not sure we can make an informed decision
20:51:50 <JeniT> slightlyoff: that's reasonable: we can look at design issues for example
20:52:18 <JeniT> annevk: we can say we're interested in TC39's opinion
20:52:34 <JeniT> noah: I need to know what the TAG needs to know
20:52:57 <JeniT> ... draft of an email to TC39, on our private list, then sent on behalf of TAG
20:53:07 <JeniT> ... vote on that on a telcon, to send email on our behalf
20:53:30 <JeniT> wycats: annevk's suggestion is good, just go back say that there's interest
20:53:45 <JeniT> ... in getting TC39's opinion about good JS API design
20:54:47 <JeniT> noah: let's draft a resolution for the minutes that you can point at
20:55:10 <JeniT> ... use private list for drafts that we haven't yet agreed on as the TAG
20:55:31 <JeniT> ... usually better if this ends up in a specific WG
20:55:36 <JeniT> annevk: I think that's Web Apps
20:55:56 <JeniT> wycats: I think that TC39 should do it with people in charge of WebIDL
20:56:08 <JeniT> ... but perhaps there aren't those people or they don't have bandwidth
20:56:20 <JeniT> annevk: Cameron McCormack is driver of WebIDL
20:56:37 <JeniT> wycats: TC39 have lots of skilled resources who might be interested in working on this
20:56:51 <slightlyoff> the last time heycam was at a TC39 meeting, IIRC, was nearly 2 years ago
20:56:58 <slightlyoff> and we got good prototype linearization done
20:57:04 <slightlyoff> but that was a long time ago
20:57:09 <noah2> q?
20:57:09 <JeniT> ... a TF that has lots of people who don't have bandwidth isn't going to work
20:57:33 <JeniT> ADJOURNING
20:57:59 <slightlyoff> thanks for scribing JeniT!
20:58:17 <slightlyoff> = \
20:59:38 <Zakim> -Alex
21:12:06 <annevk> RRSAgent: make minutes
21:12:06 <RRSAgent> I have made the request to generate http://www.w3.org/2013/03/18-tagmem-minutes.html annevk
21:12:25 <Yves> rrsagent, make log public
21:18:40 <timbl> timbl has joined #tagmem
21:19:31 <noah> noah has joined #tagmem
21:22:41 <Zakim> -WG-meeting
21:22:42 <Zakim> TAG_f2f()8:00AM has ended
21:22:42 <Zakim> Attendees were Masinter, WG-meeting, +1.415.997.aaaa, Alex, ht
23:36:15 <Zakim> Zakim has left #tagmem