W3C

- DRAFT -

Technical Architecture Group Face-to-Face Meeting

19 Mar 2013

See also: IRC log

Attendees

Present
Ashok Malhotra, Jeni Tennison, Marcos Caceres, Yves Lafon, Anne van Kesteren, Henry Thompson, Larry Masinter (phone), Noah Mendelsohn, Alex Russell (phone), Tim Berners-Lee, Yehuda Katz
Regrets
Chair
Noah Mendelsohn
Scribe
Marcos Caceres, Anne van Kesteren & Yehuda Katz

Contents


Local Storage

NM: The TAG has had things to say about local storage - which APIs are good, which models are good, etc.. About the architecture, what is good, what could be better. And also about the use cases.
... who is not familiar with the TAGs finding about local storage? http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20111201

YK: I would like to broaden the discussion to talk about resources generated locally and URIs to reference those things.
... e.g., bookmarking and sharing

NM: bookmarking is not as critical because you can use your own arbitrary API
... some of this was motivated by hash bang (#!) being used in URLs.

YK: the thing to keep in mind about push state, the server needs to return the same resource

<slightlyoff> AR: the question here is about the app development model

<slightlyoff> AR:i.e., what does a local cache "mean"?

<slightlyoff> AR: the web doesn't have any sync infrastructure now

<slightlyoff> AR:which means that there's a fight

YK: in URLs, hash slash is used because it doesn't send to the server

TBL: is it helpful for caching?

YK: yes

TBL: On the semantic web, I've seen people send the fragid as a HTTP header
... because authors wanted to know what users were looking at with regards to the data (as HTTP does not send the fragid in the request)

YK: I can see why someone would want that.

TBL: but, in a browser, you can't capture the fragids all the time because you can open tabs by shift click, etc. so it's hard to track how they are navigating an app or set of data.

<slightlyoff> AR: the server has NO IDEA

NM: I'm interested in local/remote transparency: we all know how the classic google maps uri scheme works (that is, in Google Maps, JS can reconstruct the right map from the URI). But if you use those URI in a non-js capable browsers on a low-end device, the browser will still serve a rendered image of the same map. This is cool because the URI still identifies that map representation even if you don't get the UI enhancements like being able to pan/zoom easily.
... The URL should resolve for both the client and the server.

<noah> I'm saying just a bit more than the URI scheme, but yes: I think it's preferable to not bake into the names of things a commitment to implement resolution on client vs. server

<wycats__> as a general rule, people who are trying to do these things aren't listening to the TAG's findings, but do things that are economically useful

<slightlyoff> AR: In general, this is about navigating a partially disconnected graph of nodes and with ajax. Some of those nodes are "cache" or "surfaced" locally, so the role of URL is a lossy address. It doesn't encode most of the UI state; but it's an address.

YK: I wanted to talk about what people are doing today. Most of my day job is to build a system that does what everyone is the room are talking about. Peoiple are doing 2 things: 1. people are either intercepting clicks (then XHR to get data); the other side, all the links are on the client side, but all the links refer to links that are local to the client side application.
... but you should still architect your app like they are fully running off a server

<slightlyoff> AR: ...and to build those toolkits, we need to surface the idea of a graph of data that users are navigating

YK: if we want apps to be bookmarkable, then we need a scheme/model that make sense for the app/context of usage.

AM: what are you using for local storage?

YK: there is no good answer to do offline.
... you can use local storage to simulate XHR sometimes

NM: what does the TAG want to do or say about this?

YK: when you store your stuff in local storage, you need to have enough information that it's as if coming from a server.

<slightlyoff> AR: this is one of the thins the [currently private/secret] Navigation Controller design is explicitly working to enable.

NM: Is there something fruitful for us to do here that explains the model (how local data ralates to remote data ... how that data be made addressable)
... we have a finding on this but people are not reading the finding

YK: there are people who are scared of client side stuff because they are scared of losing stuff.

??: Who is the target for this?

<slightlyoff> as a first pass, it's a start

JT: we should have a central document, and spin documents for the various communities

NM: someone needs to review the finding, and see what needs to changed or if it's already good enough

YK: I will review the finding

<noah2> . ACTION: Yehuda with help from Anne(?) to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state

YK: there is also the case for private URI that are not intended to be shared

<noah2> ACTION: Yehuda with help from Anne to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state with focus on actual examples [recorded in http://www.w3.org/2013/03/19-tagmem-minutes.html#action01]

<trackbot> Created ACTION-789 - With help from Anne to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state with focus on actual examples [on Yehuda Katz - due 2013-03-26].

YK: use case to change the URL that is not in the history stack (is transient) ... for example popping up a form that is particular for a user. But the URL is not supposed to be shared.

<noah2> ACTION-789 - Due 2013-03-16

YK: In Ember, we have a system that forces you to create a new URL

<trackbot> ACTION-789 -- Yehuda Katz to with help from Anne to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state with focus on actual examples -- due 2013-04-16 -- OPEN

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

YK: you need to deserialize the state from the URL

<slightlyoff> this is about adressing something in the graph of data

<slightlyoff> that graph is defined by the app

JT: I would expect that if it's in the address bar, I should be able to use it again

<slightlyoff> (and is app controlled)

<JeniT> ok, so like a preview of a blog post?

<slightlyoff> but what I think wycats__ is pointing out is that there are states and addressable items that don't always live a long time

<slightlyoff> so the question is "what's the role of addressing for ephemeral state?"

<JeniT> that's an interesting question

AM: Caching in a very smart way.

<slightlyoff> I can add anyone here ot the github repo

<slightlyoff> just dm me

<wycats__> slightlyoff: confirm, I agree that that reflects my concern

<wycats__> I agree 100% with what slightlyoff is saying

<wycats__> the way Ember works is that segments in URLs represent serialized models. When you load a page, those models are deserialized and become the models that power the local templates. When you transition to a new state with a new model, that model becomes serialized into the URL.

<wycats__> pushState is the low-level primitive

AR: templating has state. The URL is really a state. Email clients are exactly the same way. URL address nodes in application management. so what you want to do is to build a structure that helps you address the content. Android provides a good model for this, which we should look at. We don't have a good language to talk about this stuff, wish hash bangs and push state.

YK: Anne and I will go out and read the finding, and provide our feedback.

<noah2> I'm remembering that I did a blog post on this about 2 years ago: http://blog.arcanedomain.com/2011/03/identifying-documents-in-web-applications/

<noah2> Probably nothing that would surprise anyone now, but it seemed controversial at the time

JT: There is something deeper here: moving towards a world where we have separation between the shell of the app and data.
... I'm quite interested in that from an open data perspective

AM: The finding is focused on a different idea - how do you identify application state. You guys are going beyond that with regards to going off line.

<slightlyoff> but I go INTO a level

<slightlyoff> and I go to the navigation screen for a game

NM: there are apps that are not very documenty. For example, in a car game, describing states in as a URI might not be helpful. Then there are other apps that do feel documenty, but what you want to link really depends on what the user's needs are.

<slightlyoff> AR: I don't think the word "document" is helping us here

YK: there are a bund of states in a model, and URIs represented those models and can be deserialized.

YK draws picture on board of how a URL can map to a hierarchical data model

<slightlyoff> AR: well, I think think DB state is also a bit wrong...we're talking about moving between nodes in a graph of data

<slightlyoff> (it might be relational)

YK: several segments of the the URI end up representing different models
... sometimes people want to do this for concurrent states, but it doesn't work well.
... you many have several models represented in your URI

<wycats__> YK: but at least allows people to represent their sub-app state in a URI

<wycats__> JeniT: if you're interested in this, I'd be happy to work with you as well

<trackbot> ACTION-756 -- Jeni Tennison to draft rough product page / briefing pape for "distributed web applications" -- due 2012-11-06 -- OPEN

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

<trackbot> ACTION-772 -- Jeni Tennison to with help from Larry to propose CR exit criteria for fragids finding -- due 2013-02-12 -- OPEN

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

<noah2> close ACTION-772

<trackbot> Closed ACTION-772 With help from Larry to propose CR exit criteria for fragids finding.

<JeniT> ACTION: Jeni to do new Editor's Draft of fragids spec for approval to publish as CR [recorded in http://www.w3.org/2013/03/19-tagmem-minutes.html#action02]

<trackbot> Created ACTION-790 - Do new Editor's Draft of fragids spec for approval to publish as CR [on Jeni Tennison - due 2013-03-26].

<noah2> scribenick: noah2

Publishing and Linking

NM: Ashok, can you orient us? We need to figure out what the future will be for this work. Can you please remind our new members why we got into this and what we're trying to do?
... Ashok, can you orient us? We need to figure out what the future will be for this work. Can you please remind our new members why we got into this and what we're trying to do?

AM: Sure. This arose because of concerns about legal cases. The TAG felt we needed to clarify to the legal community the differences between publishing and linking. We haven't had an easy time striking the right balance between focusing on technical issues vs. framing things in a way that will help the legal community.
... We did this work, but reviews haven't been good: responses included that it's too complex, the audience isn't clear, and for the non-technical/legal audience it's not sufficiently clear or at the right level.
... What to do isn't clear. We could try to fix this, turn it into something else, abandon it.

TBL: Thomas Roessler had significant concerns.
... There's a concern that perhaps we cross lines where we're worrying too much about policy.
... We need to do something, not clear what.

AM: There hasn't been disagreement this is useful.

NM: I think there has been such disagreement.

TBL: At least the form is controversial

AM: OK, I think we need to think about other formats

<annevk> http://lists.w3.org/Archives/Public/www-tag/2012Dec/0139.html

<annevk> ^^ email from tlr

<annevk> https://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb is 401 for me

NM: Personally would love to have impact here. As chair, very concerned about efforts like this that keep getting reconceived and never gel.

AM: Idea on last telcon was to take one section, the publishing section, and expand it.

<Yves> http://www.w3.org/2001/tag/doc/PublishingAndLinkingOnTheWeb-20121015.html

<annevk> I found http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2011-10-27.html via Google which has a number of broken links

JT: Taking bits at a time seems reasonable.

<Ashok> http://www.w3.org/TR/publishing-linking/

NM: Jeni, you interested in actually doing this. Not sure it's the highest priority for you.

JT: (pauses...looks conflicted) right, it's probably not highest priority

NM: I also want to raise the suggestions Larry's made that this relates to governance: http://blog.arcanedomain.com/2011/03/identifying-documents-in-web-applications/

AM: I might be willing to contribute time on this, even as an outgoing TAG member

<slightlyoff> is it not sufficient to say "we believe that publishing is not the same as linking"?

<JeniT> noah: one of the lawyers we talked to said that they wanted it published as a Rec because it has more weight that way

<slightlyoff> the audio on FT is actually better than the bridge = )

<slightlyoff> thanks to plinss for that

<JeniT> [we assess feeling in the TAG]

<slightlyoff> JeniT, can that REC be that a one-liner?

<slightlyoff> 'cause i think we could get 100% support behind "The TAG believes that publishing is distinct and different to linking in both intent and impact. This is fundamental to how the web works."

<JeniT> slightlyoff, well, there's boilerplate in Recs that would make it more than one line, and probably it would have to have a bit of explanation around the diff between embedding & linking to make it make sense

<JeniT> otherwise, yes

NM: How about we agree, Ashok, that you do any further work it's at your own risk, but I will commit to at least asking the TAG to review whatever you come up with.

<darobin> if we can kill two birds with one stone, we could ask W3C to make the REC boilerplate one line as well... that'd give us a two line spec

<slightlyoff> I don't know how to change the audio levels on my side from FT vs. Google Voice

<slightlyoff> will try to figure that out, though

<slightlyoff> apologies.

YK: I would be more sympathetic of a group like EFF reached out to us.

JT: We did have early input from Thinh Nguyen, who had done legal work with creative commons.

YL: We had some request from the membership

TBL: People don't know to reach out to the TAG

YK: I doubt the people doing the arresting will read this

TBL: We're not expecting that

<slightlyoff> figured out the speakerphone = )

NM: We are hoping to offer something to the defense (or prosecution) lawyers and judges who may wish to better understand how the system they're discussing actually works

ACTION-776?

TBL: Publish as a note first, and then work on making an excerpts better

AM: Could do excerpt first

JT: Isn't it better to get the whole thing out there?

AM: Ah, OK, I guess so.

ACTION-776: Due 2013-04-02

<slightlyoff> I support publishing a trimmed version of this ASAP, FWIW

ACTION-776?

ACTION-779?

close ACTION-779?

ACTION-667?

<slightlyoff> I'm not on the queue

<slightlyoff> (I think)

<slightlyoff> yeah, i have nothing to add beyond what I just typed above

JT: I think it was just a time management

<Ashok> Alex, by "trimmed version" did you mean one section or the whole doc trimmed down?

<slightlyoff> Ashok: whole doc trimmed to what you think is the meat. Honestly, when you think it's good, I'm fine with it.

<Ashok> OK. Thx!

<JeniT> see http://www.w3.org/2001/tag/2011/12/evolution/Registries.html for background on registries

NM: I'm curious, do folks feel like the TAG should dig into improving the situation with registries?

AVK: I think the community is using Wiki pages

YK: Maybe we should see what the community does first

JT: A possible role for the TAG is to get people thinking about the solution.

AVK: I think somewhere between wiki page and central is the answer.

NM: Are you sure it won't be much harder to get right after ad hoc things are done?

AVK: HTML group is still trying to figure out what to converge on.
... IETF has heard feedback and is working on improving things
... They're getting better at quick registration, even without specs

NM: Tim, my perception is that registries have been important to you. Am I right, and are you OK with the TAG "backing off" in this space?

TBL: I think I'm OK with backing off a bit [scribe is having trouble getting the nuances of what Tim is saying...I think he's basically saying that watching and listening for awhile, and fact finding, is ok]
... Well, we've tried to avoid central registries, prefer using URIs and avoiding centralization. We seem to depend on DNS, but would prefer if that were the only registry.

AVK: People use registries instead of URIs because URIs are too long.

TBL: There's the default base URI approach

NM: As used in ATOM and for some other thinks.

<JeniT> timbl: sometimes it's useful to have a centralised registry to prevent proliferation

<JeniT> ... it depends on the context in which the values are used

TBL: We need to remember there is a cost to deploying things. So, the design point is not necessarily to encourage users around the world to do 10 a day new ones.

<slightlyoff> isn't this about huffman coding?

<slightlyoff> how long is the break?

<slightlyoff> that's me

<Marcosc> scribe: Marcos

<slightlyoff> how do I identify +44... as me?

<Marcosc> scribenick: Marcosc

Discussion with Jeff Jaffe

<slightlyoff> thanks JeniT! one of these days I'll get the hang of this W3C thing

NM: we don't have a set agenda for this discussion
... Noah introduces everyone ...

JJ: Going to spend a few minutes describing what I would like to see the TAG work on....
... like any WG, the TAG does it's best work when it's working on what it wants to work on. Happy to see new blood in on the TAG. I would like to reflect on what I think are the big issues for me personally. Reflecting on what is going on in the real world, with regards to web arch: web security is the big issue.

You read about it every day in the news paper. The security issues of the web are quite striking and often reported. The lay person may think that the TAG is likely working on to fix that.

<slightlyoff> I am contributing directly to CSP 1.1

JJ: security is at risk on all sorts of levels (from technical to social engineering), so it's quite challenging to fix.

<slightlyoff> also, I'm working on an extension that will let users control their experience WRT to XSS: https://github.com/slightlyoff/CriSP

JJ: its time to implement the fixes. When I think about this, I don't know where to turn at the w3c, so I turn to the TAG. Second thing, constructing a coherent Web architecture from the odd 60-70 groups. The fact that there are lots of groups are not coordinating is an issue - so this is an opportunity for the tag to help.

<slightlyoff> I'd like to vhemently disagree too

<noah2> MC: I somewhat disagree...the original idea was that the vocabularies would be decentralized.

<slightlyoff> well, *some* people do

<slightlyoff> but we don't have much data today

<slightlyoff> thanks

JJ: Third area of opportunity - centralised vocabularies ... a bunch of companies put together schema.org as a place to track vocabularies. Why didn't the W3C think of that?! They've done a great job. The important things about schema.org is that someone is caring for it.

<slightlyoff> happy to wait

JJ: The big miss was not the centralisation, but that we didn't provide a way for people to find these centralised sources. We've started a head lights exercise to help us look into the future in certain areas - it would be great if the TAG could contribute in identifying gaps.

<JeniT> I think this plays to the layering question

AR: Thanks Jeff. It's not that the w3c missed an opportunity with schema.org., the Web has documented it's own semantics (e.g., micro formats). What the TAG could do, can't start to inject the perspective and ask wg to add evidence with regards to vocabularies.

<slightlyoff> JeniT: yep. It's all about trying to create an environment that reaps the best from every generation and puts it in the "dictionary".

JJ: my view is, if we have something that is critical to web technology, why was the TAG not involved in that?

AR: I don't think it's fair to say that schema.org has succeeded.

<JeniT> Jeff, your point is that you need the TAG to raise these kinds of issues to you, right?

<jeff> Yes, Jeni, Thanks.

<slightlyoff> how is this relevant? we've clearly failed, as jeff says. HTML hasn't evolved to include these common nouns and verbs

<noah2> Wondering if we're diving too deep on this one item, which I think Jeff introduced as an example of a case in which he would have welcomed an earlier alert to community developments

TBL: I don't agree that we missed an opportunity. We've discussed this long and hard, we've had conferences about this, etc. There is PhD on this problems, etc. Meanwhile, yes, these groups have been somewhat disconnected from the W3C. There has been some pushback from certain places. So, the semantic web folks regrouped around "linked data", and various groups started producing data like UK gov. Going back to schema.org, the w3c and various communiti

es have been trying to find solutions for this for many years. The cynical folks say that there wasn't enough big players involved... it's a big topic. Maybe it's time to bring together what is happening at schema.org back to other communities.

<JeniT> perhaps one answer is to work out what the big companies are going to worry about

<slightlyoff> I think we missed signs much earlier

<slightlyoff> microformats, JS libraries, WAI-ARIA

<slightlyoff> the TAG missed the boat on all of those

TBL: so, it's not like there has not been an attempt to address this issue of centralisation.

<slightlyoff> schema.org is just the latest in a string

<JeniT> slightlyoff, so what's next?

<slightlyoff> JeniT: we watch the web as it's evolving, try to encourage paths that reduce friction to evolution, and help WGs pay attention to that evolution

<slightlyoff> JeniT: we can be agents of change for data-driven spec evolution

<JeniT> slightlyoff: sure, and that's what the TAG thought that it was always doing, and yet as you say it misses things

<slightlyoff> JeniT: it's in our charter to say "data can bear on this problem, why don't we look at it?"

<slightlyoff> JeniT: sounds like the TAG looked at things that weren't the public web

<JeniT> slightlyoff: what does your examination of the public web tell you *now* about the things that Jeff needs to worry about?

<slightlyoff> JeniT: I'm trying to figure that out: https://github.com/slightlyoff/meaningless

<slightlyoff> JeniT: and trying to build tools to help tell us what we don't know

<slightlyoff> here's what my browsing for the last week or so turns up: http://meaningless-stats.appspot.com/global

<slightlyoff> hopefully this extension/reporting system can be released soon

<noah2> JJ: describes successful workshop on ebooks, points out that Pearson (spelling) has just joined W3C. In general, TAG may want to consider innovations in this area.

JJ: last month we had a very successful workshop on e publishings - with great participation. We concluded that the that industry has a strong reliance on W3C technologies. If we were to work closer together, we would have a richer web. We have a call next week so the CSS wg can coordinate with the pub community. There are some other workshops coming up. When new industries get involved, it might be good for the TAG to be there to help make links.

<slightlyoff> I'd like to understand Jeff's focus on security

<slightlyoff> what JeniT said = )

JT: Can we talk about security

?

JJ: sure

<noah2> JT: Ah.. not that I have anything particular to say...we recognized it's big. I'm still not sure we have the expertise.

<noah2> +1

<wycats__> 1+

JT: We might not have enough people in the TAG with a background in security.

<noah2> JT: What is W3C strategy?

<noah2> JJ: We have working groups...(names them)

JJ: we do have a number of groups focused around security
... but my perspective is that, while we do some security stuff, we don't address security at large
... For example, I was reading the discussions about DRM and people complaining that it's broken. But the Web itself is "broken", yet we have standardised the platform...

AvK: Can you be more concrete?

JJ: example 1: in the press, the Chinese governments has been running an operation to go through the web and attack information resources around the web.

AvK: But there are many layers at where this could be happening

<Ashok> We need some "out of the box thinking about security" ... the current approaches do not seem to work

<slightlyoff> Yves: heh

YK: We have elite hackers that can break into anything. That's a poor understanding: there is poor security on the Web and people don't understand that.

<timbl_> http://news.sky.com/story/1053970/chinese-militarys-global-hacking-hq-found

JJ: I was not proposing that the TAG can fix social engineering problems. Though there might be some technological solutions to fixing some problems, like short passwords.

<JeniT> isn't the SSL CA issue is something we should push on?

<slightlyoff> yeah, compared to DNS ;-)

<JeniT> because no one else is

JJ: The core Web architecture itself is not impervious to attack

<slightlyoff> SSL CA issue is governance. Certs are being devalued every year.

<slightlyoff> see SSL EV

<JeniT> slightlyoff: so, what's the solution to that?

<jeff> [To the point of lack of security expertise on the TAG; I believe that the TAG could study something and bring in additional experts.]

<Zakim> noah, you wanted to talk about how TAG is consituted

<timbl_> SSL MITM

<slightlyoff> jeff: that's fair. CSP is currently our best hope against XSS, which is our ring-0 attack

<jeff> +1 to delegation

<slightlyoff> jeff: and I'm working with the CSP WG directly

NM: The TAG is an interesting body in its makeup. We choose more or less what we work on - but TAG's scope is huge given that it covers just about everything. The membership did a really good job at selecting a good range of people with a range of skills. Although we have managed to do some things well as the TAG, the TAG doesn't have a good track record with regards to security.

<annevk> This is the second time I've heard about two webs. For an organization that cares about One Web this is surprising.

JJ: if we had a new Web, we could address help communicate how to address some of these security issues.

<slightlyoff> btw, Mozilla deserves props for driving CSP

<slightlyoff> this isn't unknown

<slightlyoff> composition under mutual suspicion is hard, but not unknown in the literature

<slightlyoff> and that's why the web security model looks a lot like capabilities

TBL: Historically, SSL used to give users a fake sense of security. The TAG suggested the Web Security group, which maybe have helped fix up some of the UI issues around the SSL padlock. There are two areas that the TAG that could help: where JS code comes from (which can come from anywhere) but all running in the same scope. Second area, Mark Nottingham mentioned man in the middle attacks using SSL by installing fake certificates. Happened also in ce

rtain countries. So there is real shakeup needed in the whole browser certificate model.

TBL: is there was one thing, SSL man in the middle attacks... the TAG should talk to groups and make sure they are aware of the problem

<slightlyoff> it's actually hard to describe what that mode is.

<slightlyoff> I'm working to build a profiling chrome extension that helps you understand what the baseline trust is

<slightlyoff> so you can lock yourself down to that

YK: the main issue with CSP, it does not define a "mode". What I think is desirable, is to provide advice is: if you are starting a new site, this is the headers you could use.

TBL: the validator could also help with validation help check about CSP.

<slightlyoff> if you dissalow inline script via CSP, inline handlers are already disabled

MC: it's like web lint for CSP

<wycats__> slightlyoff: but there is no validator that yells at you

<wycats__> no linting tool that complains in your editor

<slightlyoff> wycats__: just load the page and look at the console

JJ: the TAG needs to think broad of the large issues.

<slightlyoff> wycats__: also, i'm looking to get events added for inline reporting

<slightlyoff> wycats__: 'cause right now you can use a report-only URL to see violations, but that's a bit spammy in the spec

<wycats__> slightlyoff: that assumes you can install the CSP header

<slightlyoff> wycats__: see the chrome extension

<wycats__> slightlyoff: I want it in my editor ;)

<slightlyoff> wycats__: the goal of the extenion is both to help you lock yourself down and to build good policies forsites

<slightlyoff> wycats__: Mike West and I can use help on the configurator UI

<wycats_> scribe: Yehuda Katz

Polyglot

<wycats_> Date: 19 March 2013

<ht> scribenick: wycats_

<slightlyoff> I may need to turn off the FT to participate by phone effectively

noah: Polyglot is a contentious topic. Can we have Henry remind us of what TAG and HTML WG have already done?

ht: We filed a request ages ago that said we would like to see a polyglot spec on the rec track

noah: I don't think we said rec track

JeniT: TR space

<noah> TR space also includes W3C Notes

ht: the WG produced a working draft
... about 6 months ago without any other event occurring, Henri Sivonen requested that the TAG withdraw, and that's where we stand

JeniT: we responded to that request

<noah> http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html

JeniT: that turned into a bug on the polyglot spec to add a status
... that bug has now been assigned to somebody

<noah> Here's the original request from the TAG to HTML WG, as conveyed by Sam Ruby: http://lists.w3.org/Archives/Public/public-html/2010Mar/0703.html

ht: I'm assuming that we're in normal W3C ground rule space
... TAG made a decision to make a request
... until we make a decision to withdraw the request, the request stands

noah: that's formally true, but I'd rather not emphasize that in order to avoid raising tensions just now
... we won't rescind without something resembling consensus

ht: the bar is higher for changing your mind than for a greenfield decision

noah: you're right but again, I'd rather not emphasize procedural issues just yet
... this request was sent by Sam Ruby on our behalf to the HTML WG
... my recollection is that the history of this was that there was some contention about this
... we arranged a F2F at TPAC with HTMLWG and TAG

<masinter> i would change "work identically" to "be equivalent" personally

<masinter> in http://lists.w3.org/Archives/Public/public-html/2010Mar/0703.html

noah: I thought we had consensus to have Sam do this

ht: I don't remember

noah: then that's my speculation

<masinter> or "work equivalently" perhaps. it needs to be a useful equivalence

<noah> Sam's original request.

<noah> Sam conveyed this to the HTML WG saying it was "an action item from the TAG" http://lists.w3.org/Archives/Public/public-html/2010Mar/0703.html asking for a polyglot spec "in TR space." Noah >thinks< but isn't sure this resulted from joing HTML/TAG F2F discussion.

<noah> About 6 months(?) ago Henri Sivonen asked HTML WG not to go this way....(and pick up with description above)

noah: As Henry says, the formal situation is that we made a request, and the HTML WG hasn't formally answered us.
... let's hear from TAG members who want to convince us to change our position on this

<slightlyoff> need to redial

noah: opening the floor for 10 or 15 minutes to listen to pro and con arguments
... Anne was suggesting that you [Alex] may be useful to speak to the concerns

<masinter> I think the request is fine, except that 'work identically' is probably too strong, 'work equivalently' would be fine and much more useful

slightlyoff: I'll try to be as even handed as possible but I have an opinion
... what is in the channel matches my knowledge of the archaelogy
... (1) there seem to be a series of unstated assumptions about what we would like to happen and what can happen
... polyglot *can* happen
... it's relatively clear that we don't know for sure how important this is

<JeniT> I don't think we should be wasting time talking about pros and cons of polyglot, more relevant is whether or not changing the request will (a) make any difference and (b) make a positive difference

slightlyoff: we have a theory

<masinter> the origin of the request was earlier in the HTML/XML task force discussions

slightlyoff: I think there's concern from Henri Sivonen that we might be giving what appears to be advice, when it may simply be the case that the document is outlining one potential subsetting. Intent vs. observation is one way to characterize it
... there is no signpost to suggest whether a document is polyglot or not
... and there doesn't appear to be a strong argument for how or why to publish in polyglot so other people know
... which seems fatal to the intent argument

noah: can you clarify?

slightlyoff: there's a signage question
... how does anybody know whether there is more or less polyglot or if anyone is publishing polyglot
... you would need to parse both HTML and XML in order to determine it
... it doesn't seem to me that the arguments about intent hold much water
... as a note that describes a state of nature I think polyglot is fine
... but I don't think it rises to TAG's level of interest
... I would like to understand from the folks who designed it whether it is meant to be intent or observation

<Zakim> ht, you wanted to make the arch. arg't

ht: let me try to make the case
... I think the grounds for the case are most easily motivated by making the historical parallel that Larry made in his recent email
... with the benefit of hindsight, the consensus position is that the W3C made a mistake 6-7 years ago with XHTML
... with the idea that the W3C's spec-writing and related activities would focus exclusively on XHTML

<masinter> I worked on XHTML in the HTML working group in 1999-2000 when I worked for Xerox and then AT&T

ht: and that "HTML would wither away"
... because of the manifest benefits of XHTML
... we were wrong

<noah> Larry sent a number of emails, but I think the one to which Henry refers is: http://lists.w3.org/Archives/Public/www-tag/2013Mar/0082.html

ht: it's cost us a lot to scramble back
... I think it would be exactly as culpable to believe that HTML5 is the way forward for the web

<masinter> the only "mistake" was to have a HTML working group at a time when Microsoft & Netscape were trying to kill each other and neither were participating in the HTML working group

ht: I don't think it's unreasonable on the part of some people to feel that polyglot is a sort of last ditch effort on the part of those no-hoper XML folks to keep a toe-hold on the web
... I want to say that just as it was a very fortunate thing that we added the relevant appendix to the XHTML spec about interop with text/html
... it seems to be precisely the reason why polyglot ought to be document
... not because we're pushing or endorsing it
... but because as Alex said, it's factually the case that the subset exists
... what are those goals?
... people with "certain goals" will have benefit from the description of the subset
... it is evidently the case that people want to do this
... the W3C owes it to its constituencies to make it convenient and gracefully interoperable

wycats: can someone please describe the use-case crisply?

<slightlyoff> does rescinding the request change the predictable outcome?

slightlyoff: we want the web to be safe for people who believe that their constituencies need XML that is parsable and displayable with minimal failure as text/html

<Zakim> noah, you wanted to make the case that having a spec is useful

<JeniT> slightlyoff, if it doesn't, why rescind it?

noah: I agree with people who say that it is an emergent property of the spec that you can do this

<slightlyoff> JeniT: because of the confusion about intent vs. observation. Why should the TAG be in the middle of this debate at all?

noah: the reason I think having a spec is useful is so that people can refer to it formally
... which I think is very important
... I think we have seen evidence that the use of this is non-trivial
... the statistics of things that are polyglot in the wild is likely low

<ht> Graham Klyne, in the email thread "As a developer, I really want to know there are patterns I can

<ht> generate that work for the widest possible range of clients (browsers

<ht> and otherwise)."

noah: we don't have a firm grip on how many people are doing it
... but does anyone really doubt that some people are trying to do it
... XML is a W3C technology
... people will want to use it to publish documents that are also text/html

<masinter> I would argue that if the HTML working group declines to pursue it, the W3C should spin up some other activity to pursue this instead. That is, the recommendation to the Director to ensure that some working group publish a polyglot spec.

noah: these could be gas pipeline markup whatever
... I think it's good to give people a spec they can point to

<slightlyoff> I don't disagree with any of that. But what does that matter to the open web or the TAG, particularly if that spec is on rails no matter what we do?

noah: I think having a spec that says how people should do it is valuable
... I don't think it's very expensive
... we can put status notes about encouragement

annevk: I think the expense...

<Zakim> masinter, you wanted to talk about threshold of interest

masinter: I think the TAG made a request
... the TAG made a request

<slightlyoff> but will that kill the effort? I don't see how it would?

masinter: withdrawing the request would send a signal that we don't think it's important
... polyglot is a transition technology that allows you to... anytime you have one to many communications...
... any time you have a network communication

<slightlyoff> do I read the HTML WG differently than masinter does?

masinter: any time you have multiple recipients and single sender
... and you want to transition from one technology to another
... you need a definition that people can use to transition
... this is an important sub-topic of the long-held versioning topic
... this is an architectural principle
... enterprises may be able to handle it, but it's not effective for the web
... it's an important understanding for how the web differs from other distributed systems

<slightlyoff> why does that have to do with the WG dropping or keeping the Polyglot spec effort?

masinter: it is an architectural principle
... we want people who are currently using XML tools

<noah> FWIW, I think Larry's argument makes sense, but it's not the one that motivates me. I don't necessarily see it as a transition: I think XML will live a very long time and will be used for purposes that overlap with uses of HTML. I expect that the communities that invest in XML for other good reasons will be the ones who use polyglot, not just as a transition, but as long as XML is useful to them.

<slightlyoff> would rescinding the request kill the effort? I get the sense no. What do you think masinter ?

masinter: is this worthy of a recommendation
... the % of this is rather small, but the web is a trillion dollars in the world economy, so even 1% is billions

<slightlyoff> how is the REC question even in our court?

<slightlyoff> I don't understand

<noah> Alex, could you clarify "kill the effort". Are you saying that the HTML WG will write and publish in TR space a polyglot spec anyway?

there's an opportunity cost

<slightlyoff> noah: that seems to be the case

scribe: it's worth paving the cowpath

<slightlyoff> that's the sense I got from Sam

<noah> Yes, of course there's an opportunity cost. The TAG was making the case that the value justified it.

<slightlyoff> it's within their charter and they have volunteers going ahead

<Zakim> wycats_, you wanted to discuss why those are not the same thing

that isn't the argument Larry was making noah

he was making the case on economic terms without considering opportunity costs

<noah> Hmm, what did I miss?

slightlyoff: I had a couple of questions

<masinter> My points were in email & irc log so this is just reminding

slightlyoff: it didn't seem to me that there was a particular sense that the TAG has anything to do with this
... if the TAG rescinded the request, it wouldn't kill the effort
... they're going to do this regardless of what we do
... this is a process question

<masinter> http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html requested Rec

<noah> The TAG is concerned because we want to be >sure< that the W3C is appropriately supporting the coordinated rollout of two related technologies. Cross technology and WG coordination is part of our formal mandate.

slightlyoff: assuming that the TAG made this request, and assuming that it rescinds it, what does the "signal" it sends affects the effort

TBL: The TAG is responsible for things that span groups. This does.

<slightlyoff> but this is about 2 specs both being published in the HTML WG, no?

annevk: I just wanted to point out that we tried this before
... it was Appendix C of the XHTML spec
... and it failed miserably
... people fail to produce that content
... it seems to me that some people can do it
... IE now supports text/xml

<masinter> if Appendix C "failed miserably", why is it that > 6% of web sites are parsable as both HTML and XHTML ?

annevk: it seems to me that actually doing it just makes your pipeline more complicated and isn't actually necessary

<slightlyoff> masinter: vs. the hoped for 100%?

annevk: you need both an XML and HTML parser to consume the content

timbl: no, you just need one

<slightlyoff> masinter: doesn't pass any class I was ever in = )

<ht> XSLT specifies, and XSLT tools support, the production of XHTML per appendix C, and that path is widely used

timbl: publishing as polyglot supports the greatest number of consumers

annevk: you can just publish as XML if that's what you want
... it will work everywhere

<slightlyoff> I still haven't heard any response on the process issue that satisfies me

<masinter> i never hoped for 100% when I worked on Appendix C in XHTML ... that's a mis-characterization

<slightlyoff> timbl, masinter: can you try?

timbl: the sorts of examples that people use this is for example to work with XSLT

<ht> I'm about to, just waiting to get off the queue

<slightlyoff> address the process issue. What happens, in your view, should we rescind the request?

<noah> Alex, is your process issue: why is the TAG involved? Tim and I have offered quite consistent answers on that: the TAG has a formal mandate to help with technology issues that cross WGs.

timbl: it's bad practice to need an XML copy and a translated HTML copy

scribe admits he doesn't fully follow the argument

<slightlyoff> noah: but this isn't cross WG. This is just XHTML and HTML, both of which are in the HTML WG

<ht> I consult for people who sell and maintain XHTML toolchains

timbl: how many people have used or built large XML system

wycats_: I have written a book with XML
... it was one of the most miserable experiences of my life

<slightlyoff> I've written huge systems in DocBook

timbl: to what extent is the W3C only browsers

<slightlyoff> also miserable

<slightlyoff> (custom XSLT-FO, etc.)

timbl: do we believe the XML community will wither and die?

<masinter> everyone knows someone who has worked with XML tool chains on HTML. I've certainly done so myself when building an internal web site

<slightlyoff> noah: what am I missing? isn't this all HTML WG?

annevk: are we talking about producers or consumers

<ht> The people I work with attribute _all_ their commercial value to the use of XML->XHTML toolchains

timbl: are people going to stop using XML toolchains
... at the moment people use XML

<masinter> there should be *NO* polyglot consumers

<noah> I really don't think driving this by our personal experience is the right way to do it. I think if you invited someone from Mark Logic, which has a tremendously successful product that is XML down to the screws, they would have interesting things to say.

<masinter> there are HTML consumers and XML consumers

then let's invite them!

<slightlyoff> noah: I agree that personal experience isn't data

<noah> Yes, it's not mainly a browser product. I don't know >what< they'd say, except that XML almost surely remains very important to their customers.

<slightlyoff> I'm still stuck on the question of process: isn't this all HTML WG?

timbl: if they notice that HTML looks like XML and want to use their tools for it, we can tell them that, yes it works

<masinter> personal experience *is* data if you're looking for evidence and convincing use cases to assure that the use cases are significant and non-trivial

<slightlyoff> or is nobody going to bite on this?

<noah> Alex, could you respond to what Tim and I have said about the process. You keep saying you don't see why, and we've both offered the same reason.

<slightlyoff> noah: you've said it's cross-WG, I'm saying "howso?"

<slightlyoff> noah: that's an honest question

timbl: seems to me that giving people a way to use their existing XML tools with HTML is good

<masinter> it's a threshold > one percent of the web. maybe it's "half of one percent"

annevk: if the document was more clearly scoped to be for the XML community, it would be better received

noah: TAG members who are sympathetic to polyglot are sympathetic to intros and status sections

<masinter> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20707

<masinter> it's already in their tracker

noah: to the extent that the concern is that this is fine as long as it's clear what the intent is we might tackle it on that basis

<Zakim> ht, you wanted to disagree that "the spec. is on rails"

ht: I believe that consensus is possible around the table
... around the existence of polyglot and specifying it
... but the controversy is over process
... historically, TAG's creation of the task force and interest in the issue was significantly the reason for getting the spec in the first place
... us saying we don't care does send a signal
... we were involved in getting it on the rails in the first place

<noah> From the TAG's charter http://www.w3.org/2004/10/27-tag-charter.html#Mission our mission includes:

ht: the constituencies who want it have a legit need for it
... the cost of satisfying it is low

<noah> "to help coordinate cross-technology architecture developments inside and outside W3C."

ht: we're just documenting it

<noah> This seems pretty squarely to be coordinating cross-technology (XML and HTML) developments.

<Zakim> noah, you wanted to talk about TAG's role and what will happen anyway

ht: there's already a bug to add a status section that explicitly says that we're not recommending it

<slightlyoff> noah: but it's about XHTML and HTML, one of which has a dep on XML parsing, but isn't proposing any change to XML in any way

noah: the question about the TAG's role has come up several times
... I'm curious about why this doesn't make the case
... one of our three formal mission is "to coordinate cross-technology architecture developments inside and outside the W3C"
... this is about XML and HTML
... many of the use cases were using existing tool chains to integrate XML documents to generate HTML

<slightlyoff> but nobody is proposing anything that's not an XHTML-compatible subset, right?

noah: at least arguably for some users this is not two serializations of HTML
... we're just talking about a serialization that works in both contexts

<slightlyoff> yes

<slightlyoff> that's my view

annevk: I'd rather the polyglot thing doesn't happen

noah: there are some people who don't want a polyglot spec

annevk: my advice would be if you want to use XML, publish XHTML

<masinter> if there are one to many publishers where some of the clients want HTML and others want XML, then you need polyglot for those

<slightlyoff> but nobody is talking about polyglot as XHTML + namespaces, e.g.

<slightlyoff> masinter: there's no debate over that

noah: the point is you should be able to serve it as either mime type
... and serve it however you want

<ht> That [serving XHTML as text/html] is certainly what my university does

<ht> 1000s of pages of it

<masinter> slightlyoff: so that's the use case, it's a common enough use case to have a standard that can be referenced and reviewed for suitability

noah: the cases I would make is (1) I covered why it's in scope; (2) it is different for the WG to promise that they'll do something than for them to randomly do it
... in 2/3 years if they stop doing it we can ask them why
... it makes a difference in a coordinating role

<slightlyoff> so I'm not *currently* suggesting that we say to WGs that we don't care (although I feel that we shouldn't), but this thing appears to be on rails

<masinter> slightlyoff: so why bring it up at all? it was done, the request was made, there is no reason to retract it

<noah> YK: Someone said something about the trillion dollar web. Yes and we have some leverage, but that means the opportunity cost is important

<slightlyoff> masinter: because there is a serious concern raised about the Appendix-C-style costs to the community

<noah> YK: Also, I worry that even if we say you aren't encouraged to do this, people will think you are.

<slightlyoff> masinter: honestly, I'm willing to go with big warnings about this in the document

<noah> YK: People who have no good need will go through hoops be be polyglot-valid

<slightlyoff> masinter: but I don't know why the TAG cares, nor do I think it should, but I'm willing to only argue the first for now

<noah> TBL: Not convinced. We could argue against most any spec we produce on that basis. I think we have to agree at the top of the document what it says.

<masinter> slightlyoff: does https://www.w3.org/Bugs/Public/show_bug.cgi?id=20707 cover it for you?

<noah> YK: You should not use this unless you have interop concerns.

<masinter> The "Scope" of a spec should say "What is this good for?"

<noah> TBL: Good specs don't say you should or shouldn't: they say "if you do this you will get the following benefits"

<slightlyoff> masinter: that + suggesting this should go to NOTE and not REC might get me there

<noah> YK: Not convinced, some people are compulsive about this stuff and will read it as "do it"

<Yves> note that there is also the question of updating the spec

<Marcosc> +q

<masinter> Rec means it has been reviewed for whether the technology described is useful for the scope for which it is claimed to apply. A "Note" carries no force except "for your information"

<ht> But a) we don't have that for all browsers and b) browsers are not the only page consumers.

<slightlyoff> masinter: and I'm ok with NOTE under that definition vs. REC

<annevk> RECs carry no weight either historically... E.g. DOM Level 1-3, HTML4, CSS1, CSS2 (before .1), ...

I don't understand why XHTML doesn't practically solve the "XML pipeline" issue

noah: I don't really hear consensus

<slightlyoff> wycats_: it does.

<slightlyoff> wycats_: except for historical UAs.

<ht> Making sure we are understood as supporting the proposed resolution to https://www.w3.org/Bugs/Public/show_bug.cgi?id=20707 is a positive step we should take

slightlyoff: it sounds like there's the potential for some common ground here
... Larry and I have been chatting on IRC with the open bug
... I am ok with modifying our suggestion that this go to a note not a REC
... basically it says that this is an interop tool
... and we don't necessarily recommend for all content
... I don't want to give this inappropriate authority
... I am concerned about the tenor
... everyone agrees that polyglot happens and will be described whether we do it or not

masinter: I think that the difference between a REC and a Note is that a Note is used when you can't reach agreement
... when you're not recommending it
... I think the scope of the document is critical

<noah> I don't share Larry's concern about note. I would prefer Rec, but I think Note is fine as a compromise. Note is NOT just for dead technologies, IMO.

masinter: if you're concerned about scope creep, then you do that by fixing the scope of the document

wycats: I want to hear about the use-cases for which XHTML is inappropriate

<JeniT> Note vs Rec is not our decision

wycats: if the HTML WG doesn't want to do it, we should do it elsewhere, like in XML
... when you obsolete a technology, it is a standard body's responsibility to give people a path off

<ht> I would prefer a REC, along the lines Larry is arguing, but, full disclosure, I note that in XHTML1 we find: "C. HTML Compatibility Guidelines: This appendix is informative."

wycats: the Director should get this done somewhere

<slightlyoff> we'll disagree on that point, I guess

wycats: the TAG is the shepard of technical activities
... make sure the right thing is done

<masinter> and I think a REC is necessary

noah: who would be in favor of Alex's proposal
... he suggested that the HTML WG would produce a Note not a REC
... with text on top that bounded the scope

wycats: -1

<ht> +0

<slightlyoff> +1

<noah> +1

<JeniT> +0

<timbl> +0

<slightlyoff> annevk?

<Yves> +1

<annevk> +1

<JeniT> Status is right thing to do, but Rec vs Note is not our decision

<slightlyoff> JeniT: yes, I agree with that, but we can specify what we'd prefer in our request

<slightlyoff> JeniT: the membership will vote

<noah> FWIW, I prefer Rec, partly because it represents some commitment to keep it up, but as a compromise I can live with Note, because it meets the requirement for normative REC.

Yves: not sure how to deal with new elements like <template>

<masinter> it's the TAG decision to keep the current request or rescind it. that's all we're talking about, isn't it?

<noah> YL: Therefore I think Note is preferable to REC

JeniT: the only thing that's normative in that spec is to describe what polyglot is

<annevk> -1, wycats_ convinced me it's better to stick to "if you want XHTML, use that"

<noah> JT: The only thing normative in the polyglot spec is the defintion that says: "works the same viewed both ways" The rest is informative.

wycats: it was your idea, annevk

<slightlyoff> Yves: specifically for <template>, the XHTML parsing is changing

<noah> YK: Had a brief conversation w/Jeni about, why not use XHTML. I still don't understand, but strongly feel we need to be able to answer that.

<masinter> perhaps "the same" needs to be defined, since "equivalent" vs "identical"

<slightlyoff> wycats_: can you type in IRC what you think the key question is?

<noah> JT: Use cases include "an XML fragment is copied into a page served as text/html".

<annevk> The key question is what does XHTML not have that Polyglot does.

<masinter> perhaps the polyglot CR exit criteria need to be extended

<slightlyoff> annevk: well, as a subset of both, whtever the subsets don't have = )

<ht> I also care about anyone who works for my university, or institutions like it, who do not control the media type their XHTML is served with!

<ht> Jeni's is not the only use-case

<ht> Yehuda, does that make sense?

<slightlyoff> ht: but if those folks are serving as text/html, what users are underserved? this is the signage issue write large(ish)

<annevk> ht: if you publish as HTML, you need to consume it as HTML

<ht> I.e. IE6 and IE7 are out, and they still have real market share

<masinter> XHTML is free to use XML syntax, namespaces, etc. that isn't valid HTML

<masinter> polyglot is a restriction of XHTML that producers need to know about, even if consumers don't

<annevk> thanks JeniT for naming them URLs

<JeniT> just for you

<annevk> scribenick: annevk

httpRange-14

<JeniT> http://www.w3.org/2001/tag/2013/03/uris-in-data.pdf

JeniT: [Gives presentation on why URLs in data matter.]
... started with "What is the range of the HTTP function?"

noah: httprange-14 means refers to how the TAG originally worked, it's issue 14 on the topic of httprange

JeniT: [goes through examples of cat pictures and books and their associated copyright]

[crowd demands more cat pictures]

JeniT: This raises certain questions, such as what data can I reuse, what data has X published, ...
... How to associate data with your cat pictures (i.e. metadata)
... Landing pages complicate this
... Amazon has a landing page for the book; the landing page describes the book
... Metadata can be okay if it points to the actual picture and the license is about the picture
... Can also be okay if it points to the landing page and the license is about the landing page

<masinter> use/mention ambiguity in natural language is common. 'Where are you parked?' 'I'm parked out back' (but it's your car, not you). Waitress 'Who's the ham sandwich?'.

JeniT: It gets confusing once party A uses the picture URL and party B uses the landing page URL

<ht> Larry, I used to think this phenom. was a use/mention confusion, but I no longer do

wycats_: I don't get why somebody should do the bottom one

<ht> Use/mention would be "http://www.w3.org/ has scheme 'http'"

marcosc: copy & paste

wycats_: I'd hope people don't do that

[light laughter]

wycats_: who is producing this JSON [example on screen]

<masinter> ht, ok, but 'ham sandwich' isn't use/mention?

JeniT: In the picture case Flickr provides the bottom one [landing page URL combined with picture URL license]

wycats_: I'm trying to understand why someone creating a database of metadata would do the botton one?

timbl: happens all over the place

wycats_: so is that because Flickr wants you to get to the landing page?

<ht> masinter, no, that's just a kind of synecdoche

jar: yes, but also the landing page might be the only stable URL

wycats_: We want to write another page that points to the book and says the copyright is about the book and not about the landing page

<wycats_> imagine you have <link rel="book" href="http://amazon.com/awesome-book">

<wycats_> and you also want to include the license

<wycats_> you need a way to describe that the license is about the BOOK

<wycats_> and not about the amazon page

<wycats_> <link rel="book" href="http://amazon.com/awesome-book" license="cc-by">

Marcosc: who is actually facing these problems today?

JeniT: the Semantic Web people faced this problem early on
... more and more we get RESTful APIs and eventually they'll run into this problem

<masinter> ht, isn't 'the copyright license for http://amazon.com/awesome-book is http://cc-license/ ' similar ?

Ashok: My understanding is different. Which is that does the URL point to the object or about the metadata about the object?
... If you point to the object, how do I get to the metadata?
... A somewhat differently focused issue

<slightlyoff> this is yet another aspect of 'what does a URL represent?', and we want a way to index into the nodes being represented in the data graph, not the wrapper(s)

JeniT: Having worked on this issue for a number of years there are a variety alleys we can stumble down into.

timbl: I support JeniT in avoiding ratholing

<masinter> I'd like to get http://tools.ietf.org/html/draft-masinter-dated-uri-10 out as an Informational or Experimental RFC, would like comments

<Marcosc> function http(){ return stuff;}

<wycats_> proceeds to rathole

annevk: What is the HTTP function?

timbl: It's doing an HTTP request and getting a response
... It was a bad name for the issue

noah: It's HTTP expressed mathematically

Ashok: If you create a linked data resource... you also create a metadata resource pointed to by a Link Header on the resource

JeniT: Right, so you store the resource and the description of the resource, and link from one to the other
... So yeah you could use link relations

<wycats_> http = λuri

Ashok: I think they only go one way

JeniT: you can do both ways
... I want to publish URIs in Data Primer. The basic solution to the problem is to be really specific what the various properties refer to.

<slightlyoff> so I'd like to re-frame this around nodes in a data graph

timbl: If somebody is going to be using the same technology and they want to describe both levels (landing page and thing), they need to have syntax for that or have different properties

<slightlyoff> a way to think about this is that you want a terminal URL for a page that is specifcally *about* that node

<slightlyoff> and that might not be the image/book

<slightlyoff> but it might be that details page for flickr

wycats_: If you use a system such a rel system you need to describe concretely whether you mean the landing page or the thing

<wycats_> the definition of the rel

<slightlyoff> no objection from me

annevk: I don't like it says URI so much

<JeniT> I'm quite happy to change that to URLs

<slightlyoff> annevk: it should s/URI/URL/g?

annevk: slightlyoff, yeah

<jar> hmm...

<JeniT> jar, it's the primer

<wycats_> what's the URI vs. URL third-rail?

Ashok: I'm fine with publishing. Are we going to declare range14 closed?

jar: Communicate with WGs for further work

Marcosc: It would be good to get feedback

wycats_: JeniT is working on that

<JeniT> ack

slightlyoff: Thanks for attention to detail. I support publishing this. I had a comment on 5.3
... It might be more concrete to say that there should be a URL for each piece of content you are trying to describe

<Zakim> noah, you wanted to ask about 303s

annevk: JeniT, also s/Link:/Link/ fwiw
... JeniT, trailing colon is more a URL scheme convention thing and even there...

<JeniT> ok

noah: We can publish this document to update our earlier advice

JeniT: This document provides a route for people that don't want to use 303

noah: At some point we should tell the community the intent is to close our issue based on this document

[alright, community informed!]

<slightlyoff> still no objection = )

<scribe> scribenick: someone

<annevk> still suggesting s/URI/URL/g

<slightlyoff> annevk: can be cleaned up in next WD

<JeniT> yeah, I'll roll in the comments received today prior to publication

<annevk> scribenick: annevk

noah: http://www.w3.org/2001/tag/doc/uris-in-data/

<JeniT> www.w3.org/2001/tag/doc/uris-in-data-2013-03-07/

<noah> Proposed resolution: The TAG agrees to publish www.w3.org/2001/tag/doc/uris-in-data-2013-03-07/ with modifications agreed on 19 March 2013, as FPWD

RESOLUTION: The TAG agrees to publish www.w3.org/2001/tag/doc/uris-in-data-2013-03-07/ with modifications agreed on 19 March 2013, as FPWD

timbl: We looked at all kinds of situations out there, including OGP. Some schema.org stuff...
... The question is, if these recommendations are taken, who do we need to talk to about the damage?

jar: all of them, everyone is broken

[disappointed looks]

jar: they're ambushed by ambiguity

[scribe was wondering when that would come up]

wycats_: the document does talk about hash URLs

timbl: should we have action items on the TAG to chase these people down?

jar: there are some tricky cases, like what do we tell dublin core?
... they have a bunch of properties that are not URLs
... there's no way to test that, the content is out there

timbl: you can by crawling

jar: worth a try
... you can't access whether a property is used?

wycats_: this is done many times

jar: this is good, but I'm still skeptical

wycats_: you doubt you can make an experiment?

JeniT: it's hard because in part it depends on intent

timbl: you read a couple of million and then you sample

[reference to foreign government censored]

jar: it may be possible
... the interesting thing will be what Tom Baker has to say (from Dublin Core)
... if they can change the existing properties or if that's not feasible

Ashok: or have Dublin Core ignore this document

<timbl> Tom Baker as in http://dublincore.org/about/executive/

wycats_: this is not different from any other thing we do on the web
... the path is, if you think you might break people, you try to find out ahead, then you experiment, and then you'll find out

jar: lets not pretend this is going to be an easy transition

wycats_: lets find out

<JeniT> some of these people might be happy with it being fuzzy

Summary of Action Items

[NEW] ACTION: Jeni to do new Editor's Draft of fragids spec for approval to publish as CR [recorded in http://www.w3.org/2013/03/19-tagmem-minutes.html#action02]
[NEW] ACTION: Yehuda with help from Anne to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state with focus on actual examples [recorded in http://www.w3.org/2013/03/19-tagmem-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-04-11 19:39:58 $