Draft Minutes for March 10 Telcon

Draft minutes for March 10 Telcon  are available at http://www.w3.org/2001/tag/2011/03/10-minutes.html
and as text below:



       [1] http://www.w3.org/

                                - DRAFT -


10 Mar 2011

    See also: [2]IRC log

       [2] http://www.w3.org/2011/03/10-tagmem-irc


           Dan_Appelquist, Jeni_Tennison, Tim_BL, Noah_Mendelsohn,
           Jonathan_Rees, Ashok_Malhotra, Yves_Lafon, Larry_Masinter,





      * [3]Topics
          1. [4]Administrative items
          2. [5]Approve Minutes from 3/3
          3. [6]TAG participation in IETF/IAB panel at March 2011 IETF
             (for March 2011 IETF meeting)
          4. [7]ISSUE-60 (webApplicationState-60): Web Applications:
             Hash-bang (#!) URIs
      * [8]Summary of Action Items

    <scribe>  scribe: Ashok

    <scribe>  scribenick: Ashok

Administrative items

    <DKA>  +lots welcome Jeni!

    Noah: Welcome, Jeni

    Jeni: Introduction

    Noah: Change telcon timings?

    Jeni: I think it will be ok

    RESOLUTION: No change in telcon timings

    Noah: Telcon on March 17 ... I am unavailable

    <Larry>  Leave meeting scheduled

    <DKA>  I am also available next week - and I think it would be useful
    given the number of things on our docket right now.

    <Larry>  If HT can, would go through IETF presentation

    Jar: I can help with the agenda

    <ht>  I'm in favour -- hope to have IETF slide deck revised by then

    Ashok: Regrets from me for 3/17

    <JeniT>  I can be here

    <Larry>  Just scheduling review IETF slide deck would be enough to

    Noah: Jar will create agenda or cancel

    Larry: We can review Henry's slide deck

    Noah: Dan wanted to discuss f2f timing

    Dan: There is a Social Web Summit Mtg in Berlin June 4/5. I'm very
    ... possible conflict ... could we meet a day later or the following

    Noah: Prefer not to change dates ... Dan may miss first day
    ... Tim, if you can meet a day later we can move it a day later

    Dan: I can fly directly from Berlin to Boston

    RESOLUTION: No change in June f2f dates

Approve Minutes from 3/3

       [9] http://www.w3.org/2001/tag/2011/03/03-minutes.html

    RESOLUTION: Minutes from 3/3 are approved

TAG participation in IETF/IAB panel at March 2011 IETF (for March 2011
IETF meeting)

    <noah>  close ACTION-535

    <trackbot>  ACTION-535 Draft IAB meeting slide on scalability issues.

    HT: I will create a new slide deck and we can discuss next week

    <noah>  close ACTION-517

    <trackbot>  ACTION-517 Figure out what to say about scalability of
    access at IETF panel closed

    <noah>  ACTION-530?

    <trackbot>  ACTION-530 -- Henry S. Thompson to draft slides for IETF
    meeting, with help from Larry Due 2011-02-22 -- due 2011-02-17 --

    <trackbot>  [10]http://www.w3.org/2001/tag/group/track/actions/530

      [10] http://www.w3.org/2001/tag/group/track/actions/530

    <noah>  ACTION-530 Due 2011-03-15

    <trackbot>  ACTION-530 Draft slides for IETF meeting, with help from
    Larry Due 2011-02-22 due date now 2011-03-15

    <noah>  ACTION-527?

    <trackbot>  ACTION-527 -- Noah Mendelsohn to make sure we make
    progress on ACTION-519 and ACTION-517 in time to provide input to
    Prague IETF meeting, talk to be ready by mid-March -- due 2011-02-17

    <trackbot>  [11]http://www.w3.org/2001/tag/group/track/actions/527

      [11] http://www.w3.org/2001/tag/group/track/actions/527

    <noah>  close ACTION-527

    <trackbot>  ACTION-527 Make sure we make progress on ACTION-519 and
    ACTION-517 in time to provide input to Prague IETF meeting, talk to
    be ready by mid-March closed

    Larry: There have been discussions at IETF re. Registries etc. Brief
    mtg Sunday and breakfast mtg Thursday about Registries, Mime types,

    <ht>  I will not be in Prague past Monday night, sorry

    Larry: What does TAG want to happen wrt IANA registeries?

    <Larry>  it would be useful to have more of a mandate about what
    should happen with them

    Noah: Perhaps add Registries to agenda for next week

ISSUE-60 (webApplicationState-60): Web Applications: Hash-bang (#!)

    Noah: Introduces the topic ... fuss about #! URIs ... some people
    feel that these have some downsides

    <DKA>  +1 to considering Jeni's post:

      [12] http://www.jenitennison.com/blog/node/154

    <noah>  JT: People are using # URIs; a problem is that they are not
    sent to the server in cases where you might want them to be

    Jeni: # URIs created a problem for Search Engines
    ... so they proposed a #! URI ... which takes the #! argument and
    converts to server parameters
    ... Twitter and Gawker use this
    ... problem was that JavaScript was not working
    ... problem also if Browser does not run JavaScript

    <noah>  JT: There are problems on various clients with JavaScript,
    including on my Galaxy Tab, some people don't have JavaScript, or
    turn it off. You don't get referrers, and you need Javascript to
    even see if the resource exists.

    <timbl>  I thought that the JavaScript happened to go down on the
    site was a bit of a red herring -- site can break in lots of ways --
    but the issue of clients without JavaScript is a very valid one.

    Jeni: Some architectural disadvantages to this pattern

    <noah>  Tim, I strongly agree that relying on JavaScript is a big
    issue, but FWIW Raman seems to disagree. In
    [13]http://lists.w3.org/Archives/Public/www-tag/2011Mar/0096.html he

      [13] http://lists.w3.org/Archives/Public/www-tag/2011Mar/0096.html

    <noah>  "at this point, JavaScript is part

    <noah>  of the Web platform, and trying to insist that URL references

    <noah>  make sense outside a javascript evaluation context does not

    <noah>  sense on today's Web"

    <noah>  I find that quite unfortunate.

    Jeni: We need to give some guidance

    <Yves>  Relying on JavaScript is as bad as relying on a specific
    codec for video, or image format, well, is it that bad? Depends on
    the intended audience

    Noah: How good or bad is it to rely on JavaScript?

    <Larry>  JavaScript does not "go from a URI to a representation"

    <DKA>  Another datapoint: some webapp development tools, such as
    Google Web Toolkit, generate hash URIs as a default way to operate -
    this adds to the problem.

    Noah: HTTP does not allow you to send frag id to server ... so no
    page reload if fragid changes

    <Larry>  The definition of HTML is changing to define the # fragment
    identifier **FOR HTML** to mean: for this content, send # parts to

    <Larry>  This doesn't have anything to do with HTTP actually

    <ht>  I am reminded of "a little bit pregnant" -- that the user
    experience depends on more than the material directly contained in
    the response message has been true for a long time

    <ht>  Maps? Really?

    <Zakim>  Noah, you wanted to talk about moving away from #

    <Larry>  We've put a lot of effort into an architecture which
    separates references, content types, and protocols, and am dismayed

    <ht>  +1 to TBL (based only on his q+)

    Noah: We should promote HTML5 facilities that let you send URIs and
    do not cause page reload

    Larry: We should not be sloppy about whether what we are discussing
    applies to HTTP, HTML or applies in general

    <noah>  Noah: my main point was that, where the item being referenced
    is a document-like (blog posting, twitter posting, map, etc.) we
    should assign them non-# URis as we always have. They should work
    consistently in Ajax and non-Ajax clients as necessary.

    <Yves>  Not really "sending to JavaScript" but fragment processing
    happens as described in the HTML spec and may also be interpreted by
    JavaScript present on that HTML page.

    <jar_>  Larry: don't want to lose that [...] orthogonality as we move
    forward on web architecture

    <Yves>  But clearly HTML's media type definition should be amended
    (and SVG's as well)

    <Zakim>  jar_, you wanted to say http: is not HTTP (Roy Fielding)

    Larry: Consider HTML embedded in mail etc. where scripting may not
    be enabled

    <noah>  To me, having a URI that can only be dereferenced at the
    client and using JavaScript, for something as simple as a Tweet,
    seems very unfortunate.

    <Larry>  Noah, that may be unfortunate, but it's a site developer's
    choice, not an architectural lack

    <noah>  Larry, I think our role in the TAG is to advise those
    developers on the architectural consequences of the avaialble
    choices, and for my money, #! is really bad.

    <Larry>  Why is it unfortunate, Noah?

    JAR: How the URI is processed is dependent on syntax

    <jar_>  Why does the URI pattern have to change when we move code
    from the server to the client or vice versa?

    <Larry>  Noah, i think we first need to articulate why it is 'bad',
    I'm having trouble coming up with reasons why it is bad

    <Larry>  So there's a picture on page 257 of a book, and all I have
    is the URI for the book, is it unfortunate that I have to use a
    fragment identifier to talk about that picture?

    <noah>  Seems to me it violates the rule of least power.

    <Zakim>  timbl, you wanted to say we are on the very of a possibly
    very complex (or satisfying?) architecture of things, pages, views,
    points of view, windows, queries, etc.

    Ashok: JavaScript is now ubiquitous.

    Tim: Is this the tip of an iceberg?

    <JeniT>  If JavaScript were actually ubiquitous, we wouldn't need the
    #! convention for search engines

    <noah>  Larry, it's unfortunate that if you were going to Amazon, the
    name of the book would be [14]http://amazon.com/#book123

      [14] http://amazon.com/#book123

    Ashok: Jeni, JavaScript in the client is ubiquitous

    <JeniT>  Ashok, aren't search engines clients?

    <Larry>  i'm thinking about the ISO 32000 use case (er, PDF), where
    you need uri-for-book.pdf#page=257 to access page 257

    <noah>  +1 search engines are absolutely clients with respect to the
    HTTP protocol that's used.

    <Larry>  These URIs are locators, not just identifiers

    <Larry>  HTTP URIs are locators

    <noah>  Larry, I don't think that example is the one that helps
    settle the case, because even with the traditional non-JavaScript
    Web you can argue it either way.

    <jar_>  TimBL: Use a language for expressing complex references,
    don't try to cram all expressiveness into URIs

    <Larry>  Noah, I'm not trying to settle the case, just discover some

    Tim: #! works but it's a horrible kludge

    <Zakim>  timbl3, you wanted to mention (a) that the fragid is a
    really useful identifier and (b) that the JavaScript not being a
    first class language on the web is something which could be

    <Larry>  Does it really have to be "JavaScript" or just "some
    scripting language"? Could #! work with Java?

    <Larry>  Agree with comments ... just hoping we can be more precise
    when we're talking about JavaScript vs. when we're talking about
    "active content" in general

    Tim: Why did Google ask for a static piece why not use a Global

    <noah>  The TAG says
    [15]http://www.w3.org/2001/tag/doc/leastPower.html#plp]: Principle:
    Powerful languages inhibit information reuse.

      [15] http://www.w3.org/2001/tag/doc/leastPower.html#plp

    <Yves>  Active content that has access to the URI of the document

    <Larry>  Hypothesis: #! is a way of supplying some additional
    metadata that isn't otherwise obvious

    <Larry>  That the URI using #! is not just a locator but is intended
    as an indexible locator?

    Tim: Making JavaScript a first class object would be a nifty idea!

    Yves: The issue is that in the example Gawker they are not exposing
    a document but an application

    <noah>  YL: I think # per se isn't the point. What's happened is that
    sites like Twitter have gone from exposing linked documents, to
    exposing a single application that lets you see what would
    previously have been lots of documents

    Yves: the shift is from exposing a document to exposing an
    ... media types need to define fragid semantics

    <noah>  Strong +1 to what Yves says about the shift. That's a major
    loss for the Web, if those "documents" aren't properly linkable.

    <Larry>  Noah, so what is the problem with that? Yes, it's an
    application, no it's not a document. So?

    <Zakim>  DKA, you wanted to play the mobile card

    Yves: Is #! available for all media types ... lot of things not
    nailed down ... need to be clarified

    <Larry>  They're linkable, just with #!... what's the problem?

    <noah>  Larry, just for a start, you can't crawl the links properly.
    Referrer doesn't work, right. See the whole list Jeni went over of
    what's broken.

    <Yves>  Problem is non-JavaScript aware clients (spiders, etc...)

    <noah>  DKA: JavaScript or not is not binary. Some device support it
    in a way you don't want to rely on heavily.

    <JeniT>  +1 or sometimes the Javascript support isn't complete

    <Larry>  Why can't referer (sic) be fixed, then? Isn't there some
    access to history ?

    <noah>  DKA: Lots of devices, agents, and other things the reference
    Web content that do not have JavaScript or don't behave as browsers

    <Yves>  Also it breaks in case of redirect

    <noah>  DKA: Includes things that produce thumbnails.

    <Larry>  Things that do not have JavaScript do not have HTML5, since
    HTML5 is an API to the DOM

    <noah>  DKA: Car apps that read you tweets

    <Zakim>  Noah, you wanted to remember rule of least poewr and to ask
    Tim a question and to remind rule of least power and ask Tim a

    <Larry>  If you want thumbnails or to index HTML you need a
    javascript interpreter

    <DKA>  I like JavaScript just fine, by the way. Some of my best
    friends are JavaScript developers.

    Noah: Using JavaScript all the time violates rule of least power

    <Larry>  Yes, there's a tradeoff when you design your site about
    whether you want to make people use JavaScript.

    Noah: JavaScript is a powerful language and perhaps too powerful
    ... asks Tim "Should we says JavaScript always is there and use it
    and if it's not there too bad"?

    Tim: The rule that you don't reload page ... may go away

    <jar_>  A problem is inferring operational behavior from the syntax
    of the URI. This inhibits URI reuse, since URIs have to change when
    deployment details change. if method for 'dereference' were
    decoupled from URI syntax, URIs would be cooler. Routing problem.

    <noah>  Noah: what I said was, we have published the Rule of Least
    Power, which says effectively "don't use Javascript, even if it's
    there, if HTML will do"


      [16] http://www.w3.org/TR/html5/history.html#the-history-interface

    Tim: When you select an item on the screen or highlight it, it goes
    on the address bar ... items may be from different domains

    <JeniT>  It has support in Webkit as well as Firefox I believe

    Tim: Are there any constraints when you do a pushstate()?

    <Zakim>  Larry, You wanted to talk about architecture that is less
    judgemental ("#! is bad") and more clearly defining consequences

    Larry: We will not get a #! is good/bad finding ... we can discuss
    the consequences

    <noah>  We absolutely can say #! is bad in the following ways, and
    either "don't do it" or "don't do it unless..." Web Arch says things
    like that all the time.

    Larry: #! adds some metadata wanting fragid to be converted to
    server-side params

    <ht>  I don't agree

    Larry discusses use case where you evolve the app using #

    <Zakim>  ht, you wanted to enlarge the issue

    Noah: The AJAX app would need to create a URI for example for the
    email you selected

    HT: Focussing on page refresh is too narrow ... there are larger
    class of issues hidden behind this ... interaction with search
    ... AJAX gave good interactivity but you lost indexing

    <noah>  Henry, I hear you, but I don't see how that explains why they
    went first to # (which I claim is to minimize server interactions)
    and then #! (which was to get back indexing, given that client
    limitations forced them to use #)

    HT: We need to think about the various players in the Web world
    ... lets brainstorm at next f2f

    <Zakim>  JeniT, you wanted to mention distributed applications

    HT: I will try and send mail

    Jeni: Sometimes the data comes from more than one server

    Yves: An application is a portal that gives you access to
    information ... it's not one server

    <noah>  TBL: I find it frustrating that with Twitter, you're
    interesting in 140 characters, you have framesets with content
    coming from another document. You want the inner frame to be
    associated with what's in the address bar.

    <noah>  TBL: I'd like to see someone write the alternative version
    where you get the Tweet as you want it more or less pure, then the
    javascript loads and surrounds it.

    <noah>  TBL: In the case Jeni mentions, where an app composes content
    from several sources, we should push for interoperability not so
    much at the [id of the state of the app???] level, but at the data
    interop level.

    Tim: When data comes from several sources we would focus on data

    <Zakim>  Noah, you wanted to propose next steps for Ashok

    Noah: Next steps on HashInURI
    ... several points of view
    ... why not summarize different positions and their pros and cons

    <DKA>  +1 to merging in some of Jeni's post.

    <timbl>  +1

    <Larry>  Definitely want to talk about registries, and IETF
    presentation on webarch for webapps

All the best, Ashok

Received on Friday, 11 March 2011 15:53:01 UTC