Technical Architecture Group Teleconference -- 31 May 2013

<scribe> scribe: slightlyoff

<scribe> scribenick: slightlyoff

HT: a report on DRM: web science 2013, Cory Doctorow gave the keynote
... he's a great speaker
... consistent with the buzz around the W3C's position on DRM, there was a perception that DRM is on its way into HTML
... the perception is so strong that the EFF have joined the W3C again to formally object to the re-chartering of the HTML WG

MC: Jeff answered questions on the blog and made it sound as though it's not in the way in
... and if the perception is something else, Jeff seems to have failed at setting that expectation

MC to TBL: I'm clarifying the perception as distinct from reality

HT: the perception is that the W3C has embraced DRM in HTML

TBL: what has actually happened is that EME has been added to the charter for the HTML WG

<wycats_> has the charter for HTML WG been approved?

HT: Harry Halpin invited Amelia Andersdotter who is a member of the pirate party in Sweden (elected to european parliment) spent a lot of time trying to clarify the arguments against with me
... vs. my expectation that consenting users and providers can come to a mutually agreeable arrangement about how to deliver content
... and I wanted to understand the arguments against that, both technical and social
... the argument is that the DRM technology is too early in 2 senses:
... 1.) it occurs too early in the relationship between the consumer and producer; it's in the platform at a level that is very, very low that precludes something like fair-use

YC: but that's a general argument against DRM.

HT: yes.

TBL: but what happens early?
... the decryption happens very late

<wycats_> YK*

wycats_: sorry = \

HT: it prevents anyone who has a right to extract for fair-use from doing so.
... 2.) it's too early socially
... the argument is that it's premature to bake in this model when the business model is still not baked and is shifting
... I find that less compelling, though
... I'm done with the report, now

NM: I don't think that's evocative of what you mean when we say "too early": it's really about the level at which processing must occur in the model

YK: I'm not friend of DRM, but there's no reason you can't contract away your right to fair use
... I don't find DRM generally compelling, but I don't think what she argued should change your position

HT: the reason I brought this to the TAG and not to the pub is that I'm conscious that I don't understand enough of the issues behind it to know if there's an architectural issue here that the TAG needs to look into at some later time

TBL: my conclusion is that there is an architectural issue(s)
... but it's not clear to me that many of the anti-DRM folks understand how DRM works

<annevk> What's the point of this discussion? I'm kinda confused.

TBL: but I have a box with lots of OSS and I can still use DRM'd content
... and I'd like to understand that dichotomy
... I had a conversation with lots of students where I tried to catalog a lot of the statements that were made. I tried to point out to everyone that it's actually complicated and that if you don't understand the fundamentals, you can't argue well. If you tell me that "DRM is evil", I'm not impressed.
... these tend to be arguments about what people *will* do
... perhaps, instead, you should try to prevent bad things from happening if/when hooks are there, not to preclude the predicate for bad action

<wycats_> point of order

TBL: there's also a technical piece: can you ahve more than one DRM system on one machine?

<wycats_> Tim's arguments are outside the scope of the current discussion

TBL: can you have a system that accommodates multiple roots of trust?

YK: we're either have a discussion about DRM or not, which is it?

AvK: what is the point of this discussion?

PL: this discussion is trying to establish wether or not DRM is something we want to investigate as the TAG

<ht> Wrt Amelia Andersdotter: https://en.wikipedia.org/wiki/Amelia_Andersdotter

PL: do we want to open this can of worms and invite people in to explain the merits on both sides to us?

<marcosc> +q

YK: I'm going to say something meta, and others will say something technical, I'm not sure what I'm allowed to discuss

AvK: /frustration/

<annevk> LOTS OF IT

frustration

all around

NM: I think this is something the TAG should take up, learn about, etc.

<Zakim> noah, you wanted to say problems are not all about what people will do later

PL: we're spending tons of time arguing about wether or not we should argue about this

<wycats_> I do not believe having this conversation with the constraint placed on it is useful at all

NM: there's a sensitivity about anything that can see bits in the clear, and that constrains the systems, so you can make the case that DRM has very large structural effects
... you can make the argument that where this goes will affect many people's lives
... it maybe the case that putting the hooks into HTML, we might be endorsing something other than what we've typically seen so far, ala TimBL's proposed questions around multiple roots of trust

MC: I'd also like to see the TAG invesigate this, and invite both proponents and opponents
... folks from the EFF, etc.

JT: my question would be: we should spend time doing things where we can affect an outcome, is this one of those places?
... or is this a place where these will be decided on extra-technical merits no matter what we do?

<Zakim> ht, you wanted to reply to Jeni

<wycats_> This argument bottoms out at "Netflix refuses any solution that is not hardware-enforced DRM"

HT: it seems to me that we can identify more and less damaging ways to go about this, should it go forward

<wycats_> which seems unrelated to technical merits

<wycats_> so I agree with Jeni

<Zakim> noah, you wanted to say role of the TAG is not only to affect the short term outcome

NM: there's a plausible premise in what JT said, but part of our charter is to document the architecture too
... leaving a record might be valuable

<JeniT> yes, I would prefer to spend time on things that are not ineffectual

PL: I'm hearing support for having people in, getting more data ,etc.

YK: I have a question: do we think that technical input will affect anything, particularly to content providers?

TBL: yes

YK: and they'll be OK with stuff that's not hardware-enforced DRM?

TBL/HT: perhaps

TBL: there's a whole body of thought that says they'll be happy with watermarking or something short of full-scale DRM

YK: if we rule out of order the hostage-taking arguments

TBL: yes, of course

<wycats_> slightlyoff: well said

AR: I think the TAG should do more than hold coats, it's one of the only bodies at the W3C that's chartered to have an opinion of its own

WebIDL cage match!

YK: I don't think there's a cage match with heycam
... I can give an udpate on what was discussed last time
... we have a thing in the platform right now called WebIDL; its job is to map between JS and C++ via a declarative indirection

YK is presenting: http://wycats.github.io/jsidl/jsidl.html

<marcosc> www.w3.org/TR/WebIDL/

<annevk> http://dev.w3.org/2006/webapi/WebIDL/

<annevk> (TR is out-of-date)

YK: it has 2 levels: a language semantics and a binding system to JS

TBL: can you describe all JS interfaces in WebIDL?

AR: no, WebIDL is a subset of the operational semantics of JS

YK: WebIDL users define things like "window" or DOMElement that are defined in terms of nominal types
... the most charitable way to think about that is that these are coercions about JS and C++ objects
... the primary goal of JSIDL is to remove the intermediate layer -- e.g., instead of coercing from JS to IDL to C++ and all the way back again, you instead define your interface in terms of JS objects, removing the intermediate mapping
... this lets you talk about things that are defined as JS but _just happen_ to be implemented in C++

TBL: why are there 2 levels in JSIDL?

YK: there aren't
... ToString is a nomenclature thing that is a bit confusing: it's a coercion rule about the nominal type "any"

AR: this is about not enforcing nominal types at boundaries, but declaring the coercions that are likely to occur

YK: the old WebIDL semantics had nominal type overloading that showed the issues
... WebIDL wanted an interface with a positional parameter that wanted a String vs. long in the same position to do this by something that is relatively complicated vs. the natural-to-write JS

MC: what does a "JavaScript interface" mean?

YK: let me get to that after outlining where we are in the process
... I've talked to heycam, bz, etc., and they're cautiously optimistic if I do the work

NM: are there entrenched communities of opposition? or is this about finding a path?

YK: I've heard 2 cocerns: heycam wanted to do this incrementally but I don't understand how to incrementally remove a mapping layer. He seemed to think it was about syntax changes -- which everyone wants -- but I'm after something else
... I don't know if he's fully persuaded, but he's willing to let me try
... the other argument is that there is a lot of existing tooling
... the point of JSIDL is also to be declarative, and you can imagine a mapping system

NM: but you're not specifying mapping now?

YK: no.

NM: <describes the landscape>

YK: yes.

TBL: has anyone tried this before?

MC: MSFT has done typescript

YK: TypeScript does something more nominal than this

AR: JavaScript as used today is very duck-typing-friendly, and WebIDL deals in nominal types which is really unfriendly to idomatic JS today. Evolving JS the language could go in many directions WRT types, and TypeScript is one option in that space

NM: that was clarifying intro for me

YK: most of TC39 didn't hate JSIDL, except Luke Hoban (MSFT) has the objection that WebIDL isn't the real problem
... allenwb has offered to help add things to the spec that might help in making JSIDL more friendly to ES6
... there was interest from others about a Guards proposal

<annevk> https://gist.github.com/wycats/4af955781ea1c84a3b11

YK: the other operational thing is that I've been maintaining a DOM JSIDL
... this is more natural, as it calls out that things like enums are a legacy concept
... there's some attempt to bring the terminology in line
... readonly vs. nonwriteable

TBL: is that meaningful

AR: e.g., configurability allows nonwriteable to be converted in some cases

YK: there are cases where you can re-define many of these things in the object model

AR: why void and not "undefined"?

YK: good point

AVK: I've mentioned before that it might be better to do it incrementally, and I want to try again to convince you
... every time we make small changes to browsrs, we get bug reports and have compat issues
... and I understand you want to make semantic changes where you can if there's wiggle room

YK: I'm happy to give up on that for now

AVK: if you keep it functionally equivalent, it might work, but if you change semantics at the same time, it's going to be hard to get browsers to do this

YK: good argument, and one we haven't heard before
... let me give you an example of something that's hard to convert (in response to TBL)
... destructuring and dictionary types
... it's not obvious that it's possible to perfectly translate some of these forms

TBL: many real IDL files can probably be automatically converted?

YK/AR: yeah

AR: overloading turns out to be mostly in new stuff, and I'm identifying the places no where it's happening
... and it's mostly in new stuff where people have built C++-heavy designs that reflect that thinking through to JS in an un-reformed way

YK: turns out that it's hard to think about a lot of those issues as automated conversions
... you told me that there's some issues around undefined vs. missing

AVK: bz is happy to try it out, and we can probably change this in WebIDL first
... returning/accepting Number has constraints on it now which we might need to describe more clearly

YK: I need you and bz and heycam to help flag these sorts of cases

(e.g., Number clamping)

MC: some of this is a bit harder to parse (e.g. the block for "nonwriteable")

AR/YK: not that hard to parse...

HT: what is the TAG's role here?

YK: coordination

HT: are we putting this in REC track in the TAG? or finding a WG?

YK: happy to do the latter
... where is WebIDL now?

AVK: WebApps

YK: will work with heycam on that

YL: there's a lot of coordination to do

YK: you can do a manual conversion relatively quickly

YL: there's a lot of testing overhead here too

YK: yes. Not signing up to do all of the testing and tooling, but will do the work to help improve the system to make that easier
... answer is that I'll keep the repo in the TAG org on github for now, and move it to WebApps at some point as I work more closely with heycam

PL: next steps?

YK: for now, wanted to make sure we could be correct
... more to do in TC39 space to ensure that branding works
... need to make sure that TC39 thinks that'll work with the language
... next, after that, is to flesh out the syntax
... appendices for legacy content

AR: doubling up is not going to be very friendly to the people working on bindings (in response to AVK about not wanting more than one IDL format at once)

TBL: in C++, if you're pretending to be C++, can you do everything a JS object can do

AR: JS VMs are done in C++, so yes, this can happen without a mismatch

YK: the tag can help coordinate

back

<annevk> plinss: you realize that parses as <br> right?

<annevk> i.e., more breaks :-)

<JeniT> annevk, were there two breaks?

inconsistencies between TAG recommendations and the web (AWWW)

<annevk> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cbr%3E%3C%2Fbr%3E is beautiful

YK: we should either make sure that specs bend to AWWW, or we should change AWWW

AVK: agreed. The reform agenda makes this pretty plain that we want to be about the web as it exists.

NM: we should be careful to be thinking about what's relevant for 15-30 years
... we should careful about how we change things

YK: normative language shouldn't be at odds with reality

MC: there's normative language in there

TBL: I have a lot of cynicism about MUST, etc. as used in RFC 2616, as lots of people use "normative" as an adjective, when in fact it's a relationship. When a spec says you "MUST get up on Saturday morning", it only means that when you are talking about meeting some criteria that is on the box that says "we are X compatible"
... this is conformance with some contract, not an enjoinment

<noah> + to take contrary position

MC: we have to remove the MUST, normative language in AWWW
... faking authority about making AWWW a REC doesn't help anything

TBL: it could be in TR space without being a protocol spec or similar, lots of things are there that aren't technical specs

YK: I'd be supportive of changing this to not talk about content type
... there are other headers that are used authoritatively, and content-type is perhaps a bad example

PL: there's a queue

YK: I didn't mean to start the conversation that just happened, it would be nice to take up updating AWWW
... I'm making a narrower ask, though, that we remove normative language that's inconsistent with other specs
... perhaps removing all normative language if TBL is uncomfortable with it in thing that don't have conformance criteria
... we could use other examples, e.g., CSP

PL: to NM's point, we shouldn't just go through the doc and remove stuff
... it might turn out that we'd like to keep some principles that don't have platform examples

YK: those should be agenda items

HT: on the very narrow question of sniffing, the situation is that RFC 2616 says that Content-Type is authoritative
... it governs HTTP and the HTTP URL scheme
... I'm loathe to ignore it
... second, we revised the Authoriatitve Metadata finding some time ago
... third, the wording from HTTP bis is wording that _we_ offered them to acknowledge the reality around sniffing
... there's good reason to believe that this isn't authoritative for Content-Type
... under those circumstances, I'd be happy to revise the section to add more example, but not to remove the Content-Type example, it may add clarity about the idea that you _should_ try to do it right if you can, and if you can't, see our other documents
... we shouldn't do anything until HTTPbis comes out

<noah> .Hmm, I'm sure I was on the queue

<Zakim> ht, you wanted to argue we have to respect the IETF and to ht2 to +1 to a 2nd edition for AWWW

HT: it is time to see if we can scope a viable plan to produce a second edition of AWWW
... if we could say it's a small-ish set of changes and can do it in 3-6 months, we should
... we should try to scope it to do it only if we can set parameters that enable it to be finished quickly
... I can volunteer if we can scope it like that

<Zakim> ht2, you wanted to +1 to a 2nd edition for AWWW

<Zakim> JeniT, you wanted to +1 to a 2nd edition of AWWW to reflect experience

PL: one way to do that might be to have another doc which we can undertake in parallel

JT: I wanted to support doing a second edition of AWWW and to address places where we want to reflect some new experience since publication
... it'd be good to show the path from where we are to where we want to be
... we have more experience now, so we should try to reflect that, but I don't know how to scope that
... large changes have happened since the publication of AWWW

HT: I was using code to say that there are limits on what you can do in a "second edition"

YL: you probably shouldn't introduce interop issues, but this won't happen in this caes

AVK: many groups have violated that principle, SVG, XML, etc.

TBL: does the group think that we should issue new documents to cover new areas? or should we expand AWWW?
... we could create a "Volume 2"

AVK: it was useful to me when I was starting
... but it also sounds like it's going to be a lot of work

JT: time-boxing is effective in limiting the scope

AVK: I favor a revision vs. surgical edits

JT: one of the conversations I had yesterday with Jo Rabin was about revising AWWW, he suggested it should be cut down and easier to read
... he said it's to big, too hard to read

annevk: thanks!

JT: MC's suggestion that it be in github and open to many editors wanting to change bits, might be good way to go fowrard. If it generates discussion, that's not a bad thing

NM: I suggest you announce this loudly

AR: agreed

MC: we can put a hook in that will notify the mailing list

<Zakim> ht3, you wanted to argue it remains a REC, because it _is_ authoritative about Web Arch

NM: you'd be surprised how strongly people will feel about changes

<Zakim> noah, you wanted to take contrary position

HT: I'm very strongly in favor of keeping this a REC. This being something that WGs can refer to as a way to know what they'll be judged by late in their process is a valuable property of the document.

JeniT: I'll race him = )

NM: I wanted to say something very similar. I think that AWWW serves a bunch of purposes, but it's a spec for specs. I don't think anybody disagrees that the sniffing instructions in HTML5 violate the old versions of 2616. What I see AWWW saying in its current form is "that's a violation of web architecture". Weather you continue to spell that "MUST" vs.

"must" is interesting. That this is a spec for specs is a good thing and you shouldn't run away from that and turn it fluffy. It's OK for people to make selective violations.

NM: where things are viewed as exceptions and not rules is important
... I agree it should be a REC

JT: another option for managing changes that might lead us to another version (vs. a new edition) might be to break up stuff

NM: it's useful that we have a single document

TBL: it was historically put together out of a lot of findings, and Ian Jacobs did much of the work of making them consistent and integrating them.
... we could take it apart for maintainece and put it back together.

e.g., missing JS

AR: I'd like to do something for helping people design good JS APIs before we contemplate putting this stuff into AWWW

JT: but there's even just acknowledging that scripts _exist_ that's missing

YK: pushState() is important to note

NM: that they can generate content!

AR: I'm scared that acknowledging scripts in this sort of document begs some _very_ deep questions and will cause huge changes

TBL: the value of briefing people is good. I'm having difficulty imagining that they won't have read a book on JS for Vol 2...what will we have to describe? async? the language?
... should we only describe the bits where JS interacts with things like URLs?

AR: I don't think that's reasonable. JS goes very deep into the architecture of the client-side platform. It's very very deep...fundamental.
... and we won't produce a document that acknowledges that correctly by the end of hte year

HT: we can acknowledge that *effects* of JS without doing the very valuable work of cataloging the client-side architecture
... HTTPbis is really terse about, e.g., databases
... and that's a bug

<Yves> not a bug

TBL: if we put in the minimal version, we have to talk about async, events, etc.
... and we must assume people have read a good JS book

<Zakim> noah, you wanted to talk about role of scripts

NM: I might be saying the same thing as HT, but we're talking about how to introduce the "document application model" that exists now and didn't when the original doc was written
... I think the way to do this is to put some of this new story very early in the docment
... to acknowledge that JS can dynamically create much of what the server used to build
... just saying that JS *can* do this stuff may help clarify
... I think we should bring it up clearly and very early

YK: I agree with NM in principle. I agree that what tends to happen in webapps is that you download a generic thing at a URL that then interprets the URL itself.
... historically, that might have been the role of a fragid, and now there's a fragid-like thing that's happening via regular URLs itnerpreted by script

JT: why are you saying that isn't happening with fragids?

YK: the way people were doing routing early was fragid-based, but for tactical reasons, taht didn't turn out to be effective, so they're using something more like regular URLs in practice

TBL: it goes both ways
... e.g., twitter

TBL: T.V. Raman wrote about this

<Zakim> timbl, you wanted to say we should list things people could do wrong

<noah> This is the finding to which Raman contributed, and to which Tim just referred: http://www.w3.org/2001/tag/doc/IdentifyingApplicationState

TBL: there's a pattern where much of the content is part of the page and is augmented lightly by JS but is mostly HTML
... there's another mode where everything is JS-mediates
... there's yet another where the hash isn't the content indicator, but rather the URL is
... original AWWW was derived from things we discovered that people shouldn't do
... it might be possible that we write about the current status of modules, etc.
... but going to 6 volumes about everything isn't maybe the best idea

AR: can rephrase as "we should only be trying to tell people about what only we can tell people"?

TBL: plus "what only we _will_ tell them"
... Futures? should we include advice of that sort?

AR: we should have a document about good API design first

TBL/PL: well, this would be about a Volume 2

<noah> scribenick: noah

PL: Are we agreed on doing a 2nd edition.

<slightlyoff> TBL/PL: this wouldn't be a short-term thing

<slightlyoff> PL: I'm hearing that we should do a second edition

HT: Yes, but conditional on finding a suitably bounded scope

<timbl> TBL: we should include in vol 2 things warnings about things you should not do, like don't abuse the global symbol space in JS, etc. and ways to avoid doing that.

PL: Are we reasonably informed to take a stab at that now

HT: We need to do things. Welcome help on both, but NEED help on one. 1) Put existing source in GitHub. 2) start figuring out what's clearly to be dropped, clearly to be kept, suspect, needs tweaking, etc. Not sure how best to try. Will take an ACTION to start email conversation.

<ht> ACTION ht to move the source into [private w3c] github with help from Marcos

<trackbot> Created ACTION-812 - Move the source into [private w3c] github with help from Marcos [on Henry Thompson - due 2013-06-07].

For source, look in CVS in 2001/tag/2004

<ht> It's in 2001/tag/2004/webarch-20041209

<ht> ACTION ht to initiate email discussion on how we decide what bits of AWWW to work on, i.e. to collect some starting points for the scoping discussion, with help Jeni

<trackbot> Created ACTION-813 - Initiate email discussion on how we decide what bits of AWWW to work on, i.e. to collect some starting points for the scoping discussion, with help Jeni [on Henry Thompson - due 2013-06-07].

URI Persistence

<slightlyoff> back, sorry, happy to take over noah

Henry suggests we not minute, because he will shortly provide a link to a document with all that matters.

<slightlyoff> thanks

<slightlyoff> scribenick: slightlyoff

<noah> scribenick: slightlyoff

NM: there are many people who are trying to use URLs/URIs/URNs for the long-term identity and location

HT: there are many people who are trying to use URLs/URIs/URNs for the long-term identity and location
... the TAG's involvement came out of advice the TAG made to the memebership to oppose the OASIS XRI proposal 7 or 8 years ago
... this was done under the banner that "HTTP is good enough"

HT: we had a request from members to explain why HTTP URIs were good enough
... the core ansewr is that *all* URI schemes are vulnerable to its management system
... any publicly managed naming scheme has social failure modes
... there might be things that militate against persistence, but you can't talk about it without discussing management
... we invited some curation community visitors in 2010 to discuss this
... we agreed to have a workshop, which happened in Dec 2011
... in conjunction with a curation conference
... some interesting things came out of it: new clarity, largely due to jonathan, distinguishing binding from from resolution is important
... binding == "relationship between a new name and what it is to name"
... resolution == " looking up a name in order to discover what it names"
... e.g., linean taxonomy.
... the governance for that is publication in a journal
... the authoritative way to find out is a distributed local-reference system based on some local librarian knowing where it is and providing it to you
... there's another point, which is to distinguish binding from ownership
... Johathan observes that for *persistent* names, binding is one-time
... the other new thing that came out of it is that broad agreement was reached that htere should be an open community process for managing binding for persistent names on the web
... the model is RFC #'s to RFCs
... net, to create a persistent naming system, it would have to be managed socially and adhere to the "lots of copies keep things safe" principle
... the existing domain name system is not easily ammenable to this style of use
... proposal: .arpa has special rules that might be better for this

AVK: but we don't have to use URIs, right?

HT: yeah, but the goal was to see if we could

NM: Metcalfe's law point

<ht> The projected report is at http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html

AR: ok, so many things can't easily be put into a different GTLD (e.g., .gov.uk) like .arpa, can we use this as a reverse mapping?

HT: that's the thought

YK: so the problem is that domains can transfer ownership?

HT: and that they can be taken away
... there's an arbitration process
... 3 problems:
... leased, not owned
... there's an arbitration process

YK: do new TLDs help?

HT/TBL: no

TBL: new TLDs can propose new social rules
... and I've proposed `.archive`

NM: the judgement in the room that using a new TLD is more political work than using .arpa

HT: the third problem is that people just walk away. Organizations fold.
... e.g., foaf.org
... note that resolution is separate

YK: you can imagine that you put a copy of a book under an archive domain and want to update it

HT: that's why you need a community process

TBL: the promise in general is that if you assign an ISBN, you can't stop using the relationship, but you can't re-use the ISBN

<Zakim> noah, you wanted to ask what's happening now

NM: what has happened since?

HT: nothing

NM: do you think the TAG can/should catalyze any action here?

HT: Gavin Brown came up with the .arpa idea
... but he was drowning in TLD registration stuff
... this is someplace where we could get help from the IETF, but we haven't tried

YK: why can't we do .archive?

back

<scribe> scribenick: slightlyoff

Responsive Design

JeniT: just as soon as it breaks some bit of real-world code that cares, I'll get right on it = )

Responsive design, images, etc.

annevk: thanks for that

DA: many, many more modalities
... and "mobile" is dead
... the word "responsive" is being used as an umbrella for this sort of content adaptation
... Dave Shea is re-launching CSS Zen Garden as a responsive showcase
... is there something that we need to do to encourage spec authors, writers, etc. to think about this

YK: the tactical goal that people have is to get either one thing that works for all devices, or to get one thing that works on the device you have
... I think people get sad when you have to create multiple forms for different devices
... I think people really want one set of bits that work for all devices, but on some devices that doesn't work (e.g., with resp images)

DA: but the UI might be radically different per device
... there's a nuance that the client-side logic might need to make decisions about what to do
... there's a question about being responsive to network bandwidth

YK: I think people using the name "responsive design" are trying to use the same bits to service all clients, and want to collapse all of their different axes of choices into a single point, and want to be able to automate all of this
... they are asking for the platform to help them do the right thing to manage those constraints

<Zakim> ht, you wanted to ask about relationship to ?demise? of transforming gateways?

HT: does this mean that transforming intermediaries are going away?

DA: yes, we sure hope so

NM: opera still makes a business on this, right?

YK: Google?

MC: what about Kindle Fire (silk)?

DA: there's a nuance about what sort of intermediaries there are and what they're doing
... "transforming intermediaries" vs. a "split browser"

YK: modern proxies are trying very hard not to be observable

<Zakim> ht2, you wanted to ask about where this leaves mobile [profiling]

HT: we put a lot of work into specing a way for devices to describe themselves...is that still relevant?

<wycats_> https://github.com/igrigorik/http-client-hints

MC: there's another proposal called "client hints": https://github.com/igrigorik/http-client-hints

<ht> device description working group

<ht> device description vocabulary

DA: the philosophy behind "responsive" is that the client does the work to disambiguate, not the server

NM: so this all hangs on JS? imperative code?

<all: no>

MC: there's a misunderstanding of what it means to be declarative in the CG taht's working on this
... designers are so used to having per-pixel control, they think they can just go into HTML and put in a media query and it'll be magically applies
... but in markup, you're just making suggestions

NM: that's not because it's declarative, that's because the <img> tag has that ambiguity built in

MC: the pre-parser that's part of many impls get broken by some of these proposed forms
... browser vendors reacted badly to having their optimizations broken by the proposals
... in the resp-images spec, there's now an acknowledgement of the browser perspective and it tries to marry the concerns, but it's not perfect yet

DA: has anyone talked to the resp-design community to tease out pet peeves?

YK: it's nonsensical to talk about the "resp design community". Everyone who cares about mobile is doing this
... there's some stuff like "element queries" that might make things better
... it's very hard, and browser vendors react badly to it
... but people are still asking for something

JT: there's also device capability
... input modes, etc.

AR: I've proposed a couple of times that media query parameters be extensible and it always falls on deaf ears

PL: you can't easily isolate the timing for CSS application and query resolution from the time when JS would run

AR: this can be done without implicating calling JS from CSS

AVK: we'd like to leave the timing of when queries are evaluated from the main thread opaque

AR: it'd be dirty-bit based

AVK: we've considered sync flush for the box tree

YK: the point is that it's the same sort of dirtying behavior that doesn't require sync execution
... how do we make this better? what's next?

AVK: you might nudge tab and fantasi?

YK: people keep getting met with a stone wall...how do we make sure that people don't just bounce off

AVK: css is already overconstrained...it might not be something people feel like they shoul be working on this as a high-priority issue

PL: the issue with element queries is implementability

YK: open question: what do we tell Ian Storm Taylor?

<ht> http://ianstormtaylor.com/media-queries-are-a-hack/

DA: there are 2 CGs in this area, what else is happening in the community that's working on these problems...we heard about client-hits...is there anything for us to do here?

ht: thanks

DA: is there something that we can do? should do?

AVK: we might be able to coordinate, but we don't have expertise here.

TBL: the main question is: is anyone else going to do this?

YK: we should look at what people are doing

MC: I'd like to talk to that group and give them a recommendation from the TAG
... should we tell people to use the picturefill polyfill?
... it could be nicer if it were in the platform

AVK: we shouldn't use the names that we'd like to have adopted in the public ewb

MC: we need to check with the drupal guys, but they were deploying <picture> on the web with the polyfill

<Zakim> noah, you wanted to say be careful about requiring everything to be "responsive"

MC: and we might need to go talk to them

NM: discussing this is clearly good, it's only somewhat clear to me what the TAG's role in moving this forward would be

annevk: no problem

I've got it

NM: if things are organized right, should they be doing what they're doing?

MC: it's a great thing if the feed back is "good on 'ya"

NM: I don't see anything deeper and architectural here
... I think the TAG could play a role if the community doesn't get it right
... there's a tradeoff: encouraging responsivness is a good thing to do. Increasing the barrier to putting content on the web by making harsh recommendations that people "MUST" do things is also problematic

<Zakim> ht, you wanted to say IST's blog post seems helpful (and well-explained)

HT: I've looked at some of this intro material and it's hugely helpful in understanding the problem

<JeniT> reference is to http://ianstormtaylor.com/media-queries-are-a-hack/

PL: it's not impossible, just deeply improbable
... and it has been explained

<wycats_> http://www.jonathantneal.com/blog/thoughts-on-media-queries-for-elements/

YK: could you send a link?

<plinss> http://www.xanthir.com/b4PR0

<wycats_> also see http://www.jonathantneal.com/blog/thoughts-on-media-queries-for-elements/

<wycats_> whoops

<wycats_> https://github.com/jonathantneal/MediaClass

<wycats_> a prollyfill for element queries

AR: I think this is TAG business because it _is_ architectural: the adaptation of content is core to the architecture of the client platform

NM: yes, it's important, but we don't weigh in most of HTML5
... i was responding to the particular idiom under discussion
... at the principles level, I agree that we should support adaptation

<DKA_> qq?

AR: I reject the framing, I think the TAG needs to be involved in the details in order to be an honest broker about the social disconnects between developers and vendors in this area

NM: I'm not trying to say you shouldn't do that, just don't own the details

YK: it might be worth banging the drum about layering as a solution for this area
... layering is a framing that doesn't require everyone to give up on their specific areas of concern
... and AR's proposal helps enable both implementers and users to iterate in their own space and get past this

<wycats_> http://hitchjs.wordpress.com/2013/04/17/element-queries-prollyfilled/

TBL: this sounds like a good way for the TAG to operate: acquire enough information about the specifics to be able to make good recommendations and point to in our layering advice about what does and doesn't work

<timbl> We have worked like this before, to go into specific breakage, and come out with to just opining on that and helping mediate, but demonstrating need for broader arch pricnoples.

DA: on the resp-images controversy, we have a community that's very interested in images and they care a lot -- sounds like the audio thing where htere's a community of experts -- and they've built that knowledge into the proposal and when they bring that to the larger community which is thinking about other concerns it meets resistance

MC: that's a tiny bit off....the community is the design community
... they know all about the larger context

YK: and iOS is making this easy for htem and hard for us...they're saying "why is this so hard on the web?"

MC: we want browser involvement because there are things like powering up the radio that cause extra latency
... the JS solution has raggedy edges

YK: it's not composable either
... if I use hitch.js to modify my images, I can't use other things

<wycats_> hitch.js is a CSS prollyfill engine

AVK: there are existing communities in which these things can be solved

MC: there are guiding principles that we can use and the TAG can transmit back to the community
... it's not obvious to everyone else

YK: when we write down the principles, we should higlight things like that: don't build stuff that can't be taken back if it's not part of a standard

DA: perhaps we can take that back

MC: we can't say "web components" 'cause it's not there yet

YK: we can't say "use components", but we can say "look at how that was done"
... someone should write the Polymer WC for responsive images

MC: I'd be happy to write up something along those lines

Community Groups

YK: it seems like people agree that CGs were intended for a particular purpose and it seems like they are getting used as a way to divert some folks away from WGs
... e.g., resp-images is an example of a lack of vendor involvement, and the CG worked really ahrd and the vendors were astonished

TBL: if you put people out in a CG, the WG has a responsibility to liason with that CG

DA: someone said "there should be the ability to send a pull request to a WG from a CG"
... you could think of a CG being allowed to fork a spec and allow those sorts of changes

NM: letting people patch communication problems is clearly good
... when YK said "this isn't what htey're for", I want to understand that

DA: CG's were initially set up to incubate NEW work

NM: I'd have thought that if a group wanted to do something in an area that a WG is already formed in, they should try that ifrst, but if someone finds that problematic, they started CGs ot spec that

YK: I don't think taht's what happened in this case; people who weren't WG memebers were pushed off for resp-images

MC: that's not what happened with HTML/XHTML

<marcosc> s/HTML/XHTML/WHATWG

TBL: what they were designed for should not restrict what they're used for
... there are several failure modes; sometime they go off and do work and are not respected, or they go off and don't do work
... but perhaps we should look into CGs that are explicitly spun-off from WGs

<wycats_> think of them more like "task forces"

DA: yeah, was thinking about CG's that are treated more like Task Forces and not independent entities

NM: I don't think this is particularly TAG business
... more like something we could refer to the AB

DA: not sure if it's TAG business, but it's soemthing I intend to personally take to the AC/AB

NM: I dont' want us to be process nerds, but the TAG's charter is fundamentally technical

DA: but lets not use that as a reason not to talk about things

AVK: "3. to help coordinate cross-technology architecture developments inside and outside W3C."

<noah> "The TAG's scope is limited to technical issues about Web architecture. The TAG should not consider administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee, Advisory Board, and Team."

AR: diplomats, not politicians

<ht> http://www.xanthir.com/b4PR0

<ht> That's the hard part

<ht> Here's the apparently reasonable request: http://ianstormtaylor.com/media-queries-are-a-hack/

<annevk> thanks

DA: we're due to close in 55 min....we should probably move forward. JT suggests we not talk about DWA but instead wrap up, talk about next actions, etc.

(we're restarting)

DA: don't want to re-open packaging becaues it'll eat the whole hour

Wrap Up

AVK: do we have actions we can review?

NM: they're in tracker

<noah> http://www.w3.org/2001/tag/group/track/actions/open

<marcosc> http://w3ctag.github.io/webarch/

<noah> ACTION-802?

<trackbot> ACTION-802 -- Yves Lafon to bring new W3C initiatives to TAG's attention, open-ended, due 2015-12-31 -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/802

<noah> ACTION-803?

<trackbot> ACTION-803 -- Daniel Appelquist to talk with Art Barstow and/or Charles Mac??-Neville to find out who from Webapps might come to talk to us -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/803

<noah> ACTION-804?

<trackbot> ACTION-804 -- Yves Lafon to invite Olivier Theroux to lunch on Friday due 2013-05-29 -- due 2013-05-30 -- CLOSED

<trackbot> http://www.w3.org/2001/tag/group/track/actions/804

<noah> ACTION-805?

<trackbot> ACTION-805 -- Anne van Kesteren to find a representative of Web RTC to talk to the TAG -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/805

<noah> ACTION-806?

<trackbot> ACTION-806 -- Jeni Tennison to invite Phil Archer to talk to the TAG -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/806

<noah> ACTION-807?

<trackbot> ACTION-807 -- Daniel Appelquist to invite someone from Responsive Images CG to talk to the TAG -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/807

<JeniT> marcosc: did you ReSpec that?!?

<noah> ACTION-808?

<trackbot> ACTION-808 -- Daniel Appelquist to pull together a plan for TC39 participation at TPAC in November in China -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/808

<JeniT> already?

<noah> ACTION-809?

<trackbot> ACTION-809 -- Yehuda Katz to and alex will create an initial draft of high level view/survey and how they relate to system capabilities -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/809

<noah> ACTION-810?

<trackbot> ACTION-810 -- Jeni Tennison to create a first draft of capability document guidelines -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/810

<noah> ACTION-811?

<trackbot> ACTION-811 -- Yehuda Katz to send a note to the web audio working group with some architectural suggestions. -- due 2013-06-06 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/811

<noah> ACTION-812?

<trackbot> ACTION-812 -- Henry Thompson to move the source into [private w3c] github with help from Marcos -- due 2013-06-07 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/812

<noah> ACTION-813?

<trackbot> ACTION-813 -- Henry Thompson to initiate email discussion on how we decide what bits of AWWW to work on, i.e. to collect some starting points for the scoping discussion, with help Jeni -- due 2013-06-07 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/813

DA: should we invite WebMIDI?

AR: no?

<noah> ACTION: Marcos to present on midi on future telcon - Due 2013-06-30 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action01]

<trackbot> Created ACTION-814 - present on midi on future telcon [on Marcos Caceres - due 2013-06-30].

YK: that's not reasonable since we want to inform the entire TAG

AR: good point

DA: DAP?

<noah> ACTION: Dan to invite Anssi to present on DAP/Sysapps on future telcon - Due 2013-06-15 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action02]

<trackbot> Created ACTION-815 - invite Anssi to present on DAP/Sysapps on future telcon [on Daniel Appelquist - due 2013-06-15].

<noah> close ACTION-807

<trackbot> Closed ACTION-807 Invite someone from Responsive Images CG to talk to the TAG.

<noah> Suggest we paste the URI's here for the minutes

<noah> OK, I'll do it: https://github.com/w3ctag

<noah> ACTION: Yehuda to write readme for architectural principles of promises - Due 2013-07-01 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action03]

<trackbot> Created ACTION-816 - write readme for architectural principles of promises [on Yehuda Katz - due 2013-07-01].

<noah> ACTION: Alex to write readme on extending HTML responsibly - Due 2013-07-01 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action04]

<trackbot> Created ACTION-817 - write readme on extending HTML responsibly [on Alex Russell - due 2013-07-01].

<noah> ACTION: Peter to coordinate redesign of home page, finding lists, etc. - Due 2013-08-01 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action05]

<trackbot> Created ACTION-818 - coordinate redesign of home page, finding lists, etc. [on Peter Linss - due 2013-08-01].

<noah> ACTION: Peter to set up mirroring of git repos - Due 2013-07-04 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action06]

<trackbot> Created ACTION-819 - set up mirroring of git repos [on Peter Linss - due 2013-07-04].

RRSAgent: make minutes

- DRAFT -

Technical Architecture Group Teleconference

31 May 2013

Attendees

Contents