See also: IRC log
<masinter> Date: 24 June 2009
<masinter> ScribeNick: timbl
(discussion of deployment of smart phones, vs SMS capabilities)
Noah: Do people just expect them to get IP and use the web, or will they stay with SMS?
jk: Well, phones last, with repeair services, for a long time in developing countries.
HT: Even my phone does some web, and its level is well deployed in developing countries.
NM: I would have thought that a little bit of graphics would make it much easier to make an intuitive, say, banking application, compared to just using SMS (which of course they do.)
Tim: The SMS limitation of 140 character seems to have taken off with microblogging
Noah: The person who built twitter was before that fascinated by the communication (by SMS) between bicycle delivery people in New York.
jk: XMPP is very interesting in the mobile space.
... Hybrid bi-directional protocols become more friendly than old HTTP.
... These things are being integrated in HTML5, and things like Comet which allow long-lived connections between things like a mobile phone and effecive a pub/sub service.
... Again, not clear how many of these issues are actually limited to the mobile world.
Larry: It is mobile-related in the sense that the mass of deployment is changing dramatically, so there are many more mobile phones than PCs.
... As the performance increases, that dominance will rise enourmously.
... Most people on the web will be mobile users talking to the cloud not PC users.
... We should not then only focus on the desktop/laptop architecture or we will miss this.
... I think mobile is a lot of what is fuelling HTML5 and WebApps development.
jk: Comet is HTTP long-polling .... connecting up to a server so that effectively small messages can be sent from server to client.
<DanC_lap> (is anybody on the TAG watching the new list on comet etc.? hybi is it?)
<johnk_> http://en.wikipedia.org/wiki/Comet_%28programming%29
<johnk_> https://www.ietf.org/mailman/listinfo/hybi
NM: For a bank, for example, today people often get a web site for laptop use, but a native app for an iPhone. So we have this move for lots and lots of applications.
NM: But it is a pain to wrote a different app for each platform.
... The market seems to be suggesting that the web is not good enough for these domains.
... That is why we really need good webapps, so that we build one web and they build one web application.
... Native should be for where we want to exploit the unusual capabilities of particular platforms.
Larry: If I am Fidelity, have a big back-end, I want to make it available from wherever people are. I want to adapt it at the last moment to the user. If necessary, I will build a native app.
(discussion of web applications that are just bookmarks)
Larry: I think the motivating force for web applications is mobile... the goal is to blur the line between an app and a bookmark.
Noah: On the iPhone, you can now use Web-based gmail when completely offline,. All your gmail information is downloaded into local storage from the web... ironically, you also get your Web-resident GMail contact list, but NOT (due to sandboxing) the phone-native contact list.
Jonathan: (Doesn't work for me.)
Noah: So the need now is for an API for getting at the local contact list.
<DanC_lap> (hmm... iPhone as gaming platform is getting pretty interesting. I wonder whether to bring that up here/now.)
<johnk_> http://www.w3.org/2008/security-ws/report#Concrete - device APIs currently in W3C charter
jar: There is pressure to make separate phone apps for newspapers, banks, etc, and I suspect it is because of deficiencies in APIs. This will be fixed as it was for desktop applications ... It was made it easier to install desktop apps. For browsers it will get easier.
... Our job is to think: what might go wrong as that rolls out?
... If we see some danger in incompatability between, say access to contact lists, we must work to prevent problems, where market pressure does not help.
Ashok: I don't think it will take the same number of years .. it will be faster.
<Zakim> johnk_, you wanted to mention what I see as the two possible architectural issues
<Zakim> noah, you wanted to talk about security
jk: From everything I have written down, here are two arch issues: Merging of pub/sub XMPP events into the protocol, and security and privacy in a world where you have HTTP server running on your phone ... closely connected to an individual and serving private data.
NM: The people who develop mobile devices have been more paranoid about keeping the platform secure than the browsers. Even the native iPhone apps have lock-down sandbox model.
<johnk_> correcting the "you have something which is the equivalent of an HTTP server running on your phone" to "you have something which is the equivalent of an HTTP server running on your phone"
NM: This sandboxing gives a much stronger assurance that e.g. my contact list won't get stolen or trashed. This will be an important factor for the deployment of web apps.
Larry: The history of the mobile industry and its interaction with the web has been rocky.
... WAP, CHTML, and attempts to build a separate infrastructure instead of working with the existing standards groups ...
jk: (Sometimes mobile not well listened to)
Larry: There was not an effective way of working together; we should make sure there is in future.
... With security and privacy, market forces are not as good drivers as with features.
... With features, you can deploy 20 and the market will select the ones you need.
... With security and privacy, the consequences of getting it wong is very delayed. So the market does not select things properly. So we the TAG should put more effort into those things.
... there has been a lot of handwringing but I think IETF has put a lot of work in here.
... We should understand the history and background in this area before we work in it.
<Zakim> DanC_lap, you wanted to note software installation is more about "yes, you can run your code on my behalf" than downloading bits... and wonder how much of the market the W3C
DanC: Talking about sandbox models. With client-side caching this is more about users saying "yes you can get access to this"
... Keeping the bits is not what is important, but getting and caching the permissions is important.
... Gears, or HTML5 data access are used.
Noah: You get a SQL-lite database on your phone just from visiting the gmail site, without giving them permission to use space on the machine.
<masinter> ((monetization policy is a motivation for separate apps, as well as the top level 'app' bookmarks))
<noah> As I understand it, Google has written a GMail client that is mostly portable from Android to iPhone (more to come), but is using Gears on Android, and Safari HTML5 store on iPhone.
<DanC_lap> http://www.w3.org/TR/2009/WD-widgets-20090528/
danc: On Android, there is a set of control bits for each application. Note that the widget spec is related to this, just went to Last Call.
TimBL: Isn't it a goal to make desktop and web app installation to become equivalent and connect directly?
<Zakim> johnk_, you wanted to mention the HTML5 discussion
<DanC_lap> (I can't find the list of permissions in the widgets spec; help?)
jk: There are two very important identities - the user and the company which made the app.
timbl: Don't assume the company is active as the user's agent.
jk: Is HTML5 the format we will use for new user interfaces? Or will there be completely different interfaces -- like voice interfaces -- which may need very different languages.
<Zakim> timbl, you wanted to discuss what parts there are of what we think of as installation. Access to data, accecss to resources - memory, disk, cpu, screen space, attention,
Noah: BREAK
Noah: We have four issues around this
... 57,62, 63, 54 (See the Agenda)
Larry: I have been tardy in opening a new issue-63, I was thinking about how to frame it.
Noah: Let us deal with all 4 issues in this session.
Ashok: I think we should separate the access and the format.
... On the access front, there is no new news, though Eran and Mark Nottingham has promised us a new draft.
jar: LRDD
<noah> JR: Current drafts are linked from our agenda
<Ashok> New drafts expected from Eran Hammer-Lahav
<jar> Eran and Mark are preparing new drafts, but they're not ready yet. So we can't talk about them yet.
<noah> Email from Jonathan (linked from agenda): http://lists.w3.org/Archives/Public/www-tag/2009Jun/0060.html
<noah> That email has links to drafts
Ashok: On the access part, we should just wait.
<noah> AM: On metadata access, I think we should wait
Ashok: For the format part, I leave it to Jonathan.
Larry: I have the idea that we might have an architecture for metadata which might describe the relationship of semantics for URIs and resources and semantic web assertions about resources, and the ways in which specific protcols might contain features which might advise you about other metadata, so that, for example, HTTP and HTML are just instances of more general classes of things.
When I thought abou framing the metadata issue, it was to to try not to tie the idea to HTTP specifically.
Larry: I think we can make progress on that idea independently of the way of accessing metadata specifcially.
<Zakim> jar, you wanted to talk about relation to nose-following
jar: To address that, I agree with Larry, that quite a lot of this is architectural rather than tied to some specific protocol.
... There is the "self-describing" or nose-following, web.
... that is very close to the Linked Data movement, which has developed its own protocol for browsing the web for data about anything, not just data about documents.
... One idea which runs through this is .. are we talking about third party metadata, or just about second party metadata?
... The first party might be browser, the second party the publisher, third party the reviewer?
... We should say that one can get data from many different sources. Ther are trust, authority issues.
... This is not just HTTP -- many other naming schemes, like LSID for example, have systems for getting metadata about things.
<Zakim> johnk_, you wanted to ask why metadata is different than "data"?
jar: I wanted to mention the HTTP 303 Redirect case, as an ad-hoc protocol which has emerged from the Linked Data story.
<jar> TBL: want the tag to support the Link: header
<jar> ... doesn't want anything to threaten that
<masinter> doesn't understand why we need the TAG to support the Link header and wants Tim to motivate that
<jar> jk: How is metadata any different from data [in the way it's treated]?
<jar> timbl: What its access control is, how to edit it, all sorts of things you want to know about an IR... we need this
<jar> timbl: Enables new functionality. A growing area.
<masinter> are you convinced the Link header meets the requirements for all of those applications?
<jar> timbl: doesn't want to get too philosophical about this - top-down is dangerous
<jar> ... important for the TAG to do because it's glue. A little thing that will have a big effect.
<masinter> for example, is link header really the right way to deliver access control information?
<jar> noah: How urgent?
<masinter> is prospective sending of 'Link' header a requirement for sending access control information for applications that don't care about access control?
<masinter> for example
<jar> timbl: We need to make sure the Link: draft gets reviewed, make sure it gets moved along through process
<jar> ... Also we need to make an architectural recommendation
<jar> masinter: I'm not convinced of the goal.
jar: I brought the link header draft to the TAG.
<jar> (noah had asked about the history of the issue)
<noah> Proposed ACTION to Ashok: Keep an eye on progress of Link header draft, report to TAG, warn us of problems.
Larry: I am not sure with the phrasing of the action that the HTTP Link header should be followed.
... We do we need this? for ACLs? maybe we shouldn't use it?
jar: We could work on use cases.
<Zakim> ht, you wanted to ask about authority
<masinter> i believe the requirement is important. I'm not sure the requirement is well articulated, and I'm even less certain that the proposed mechanism satisfies the requirement.
ht: I liked what someone said about the suggestion that we need an architecture for the data - metadata relationship.
<noah> ACTION: Ashok to Keep an eye on progress of link header draft, report to TAG, warn us of problems (ISSUE-62). Due 8-1-2009 [recorded in http://www.w3.org/2009/06/24-tagmem-irc]
<trackbot> Created ACTION-281 - Keep an eye on progress of link header draft, report to TAG, warn us of problems (ISSUE-62). Due 8-1-2009 [on Ashok Malhotra - due 2009-07-01].
<jar> ht: Authority is fundamental to any metadata architecture
ht: Authority is fundamental to metadata in a way that it is not fundamental to the ordinary web. [sic]
<DanC_lap> action-281 due 1 Aug
<trackbot> ACTION-281 Keep an eye on progress of link header draft, report to TAG, warn us of problems (ISSUE-62). Due 8-1-2009 due date now 1 Aug
<jar> ht: Link: is a response-header, not an entity-header ... this makes the authority chain clear
<masinter> I agree the issue about authority is fundamental to metadata architecture; not sure if it is more or less important to ordinary web, but we understand web authority better
<jar> ht: this is different from putting it in the content
<johnk_> +1 to Larry - not sure how this isn't an issue for the "ordinary web" too
<jar> ht: The server and the page provider are different principals in this scenario
ht: If you get a document and the document contains link elements, then the authority chain is clear, but if I get an HTTP link in my case at Edinburgh then I don't necessarily have anything to do with it.
<jar> john: another confused deputy problem
<jar> dan: No, it's not, just a bug
<masinter> how to distinguish between HTTP header metadata and entity content metadata and the relative authority of them is an architectural question
<masinter> ((wonder if there's some 'cascading' along with 'CSS' that are cascading metadadta authorities))
<jar> timbl: We haven't talked about how delegation works inside a web site.
<jar> ... This would be a new piece of work.
<masinter> ((wonders if appropriate to talk about XMP))
<jar> ht: But when we start to talk about metadata, it starts to become much more important (it = the question of who the authority is)
<masinter> ((relationship to content type sniffing?))
<masinter> ((WebDAV has protocol for managing 'metadata', doesn't it?))
<jar> timbl: To build a system that treats Link: and <link> as having different trust models compared to the data, would be to assume stuff about the internal social workings of the site as publishing agency
I realize Tabulator does absorb both, and does track the difference in provenance, but does trust them to the same extent.
<johnk_> The "link header" is already a framework for links, not just about the Link HTTP header
ashok: Let us get the Link header standardized so people can ge things going.
<masinter> ((want to put in a pitch for embedded metadata))
<jar> ((embedded is always better than Link: **all other things being equal**))
<Zakim> masinter, you wanted to put in a picth for embedded metadata
<noah> NM: Do we need to follow up on use of HTTP redirection in addition to link header?
((You owe me $2M **all other things being equal**)) :-0
<noah> AM: Don't think there's more we need to do at this time.
<jar> I would put trust, authorization, authentication in a bucket with access. maybe broaden the issue.
Larry: I think there is a question in the metadata architecture, what do we recommend to people, for the priority of embedded vs linked vs third party metadata ...
<jar> -- Eran has an answer to this.
Larry: People have the possibility of dealing with metadata from multiple sources.
... We'd like two agents with the similar trust model to arrive at the same concludion.
... So if you use a link header, for example, does this mean you are overriding the other embedded data?
... I know a lot about embedded metadata, spend the last couple of years working on it, and on the metadata for compound objects built out of many other objects.
... When I come to thinking about metadata, the authority issues are more prominent for me than with the web in general.
... In lots of the web, I think authority is a second priority.
... Authority on the web is more obvious for the data.
... Content type sniffing is wrong and dangerous here as everywhere.
... Is there a place for cascading, where i can override some but not all of ithe data.
<jar> [jar would like to modify his previous remark, far above, about entity-headers. i think ht was talking about the entity-body, not the entity-headers.]
LArry: I also would put into the architecture the various places wher metadata could be found.
<Zakim> johnk_, you wanted to mention text/plain and Link header
<masinter> ((or else put the metadata in the link itself))
jk: One use case is for plain text documents which don't have the ablity to carry metadata. The link header is part of what Eran is writing up as something much bigger.
<Zakim> jar, you wanted to talk about archiving of <link>-containing documents vs. Link: and to say that the link:/<link> distinction is important (in a practical sense)
jar: It would be illustrative of the tension betwen link element and link header if you can focus on this question.
... I came to the conclusion that there are different entities making these statements. Yes, one might not want to think about it, but it does make a difference.
... You may archive an old verion of the ocument at a new URI.
... You rev it because the link elment is wrong.
... One thing you might say in archived metadata would be correct metadata stating that that the link element is wrong.
... On serious archival situations, this has the potential to be important.
... This is useful to just note they are coming from different sources.
<johnk_> Making decisions about authority requires the ability for the recipient of the data to be able to reasonably authenticate the authority
<noah> TBL: There are lots examples where different people are responsible for that information. Sometimes one or the other is easy to access.
<jar> Re <link>/link: conflict we have three 'answers' on the table: Tim/Dan, HT/JAR, and Eran. Eran says sources *must* agree
<noah> TBL: The situation where you archive specifically because something was in error is a bit of a problematic path to explore.
<jar> timbl: LM, it's interesting that you think authoritativeness of metadata is more important than authoritativeness of data
<masinter> I don't
<noah> TBL: Responding to Larry, I note that you are more concerned about the "authoritativeness" of metadata than of the data. I can't support that distinction. Both are important.
<masinter> Actually, "authority" is metadata.
<noah> TBL: Lots of data on the Web, such as banking, drug data, etc. is itself important.
<noah> TBL: We can ask some useful questions: 1) how can I get metadata specifically from the source of the data and 2) how can we access (publish? -- not sure which Tim emphasized) 3rd party metadata.
<noah> TBL: How does Henry find out that Dan has "tweeted" about him? One answer: twitter.com sends an email saying "look who tweeted about you"
<jar> careful: metadata attached to the URI is not necessarily metadata attached to the resource (i.e. metadata and resource might have different "owners")
<Zakim> noah, you wanted to respond on archived documents
<johnk_> noting content-centric networking work of Van Jacobson in this area - http://en.wikipedia.org/wiki/Content-centric_networking
Noah: (Yes, archiving something and saying is is incorrect is a fringe issue)
Danc: (yes, -- suppose you archive an old price list -- you don't want people to believe it -- this isn't a metadata issue only)
Larry: "Authority is metadata". You can think of authority as metadata [sic]
<johnk_> see content-centric networking, again ;)
Larry: the mechanism by which one dicovers and reasons about authority is in general metadata.
<jar> how authoritative is the metadata? -- that would be metametadata
jar: I don't know how the TAG could be involved in metadata formats.
... W3C has been promoting a particcular way of doing it, base of standards.
... The punctuation has been provided by RDF, and the W3C story is that communities will get together and make thei own vocabularies.
<masinter> ((should W3C endorse Dublin Core?))
jar: W3C has for example recently done SKOS, but it does not have to happen within W3C in general.
<DanC_lap> 22 Jun: WebKit destined to get its own content sniffer http://sideshowbarker.net/2009/06/22/webkit-sniffer/
<masinter> ((media annotation is working on vocabulary))
jar: Every database you go to has a different vocabulary for bibliographic data.. maybe people will fix [this] if it is a problem.
<Zakim> johnk_, you wanted to now mention content-centric networking, link to the capability discussion yesterday
<jar> embedded metadata is always better than out-of-doc *all other things around metadata being equal*
jk: In this conent-centric networking concept (Ted Nelson and Van Jaconson), they are trying to tackle this, and there is a link to the capability issue
... in that the separation of data and metadata is a security issue.
<masinter> ((PDF/A ISO 19005 uses embedded metadata using XMP))
<Zakim> masinter, you wanted to talk to metadata formats
Larry: On vocabularies, these are related to formats.
<DanC_lap> (I think the POWDER spec ended up endorsing DC... or was it FOAF)
Larry: Vocabularies: should W3C endorse Dublin Core? (I was called the "Naysayer of Dublin")
<jar> lm: embarassed to say I voted "no" on all dublin core attributes, but since recanted.
<jar> lm: it would be worth looking at w3c groups working on vocabularies
Larry: I think the Video Annotation people are working on vocabs for audio and video
<raman> calling zakim
Larry: I have worked on XMP, which has three parts, the format, the vocab, and the method of embedding the format in an arbitrary document.
<noah> Raman, we're talking about metadata. I'll dial now.
Larry: The format is a non-current profile of RDF. It is however well deployed.
... There are other vendors using it.
<noah> Raman: please note that the agenda at http://www.w3.org/2001/tag/2009/06/23-agenda has been updated.
<noah> I expect we'll break for lunch shortly.
Larry: There are ways of embedding it in most media formats. There are some formats for which that is a problem, which leads to other ways of linking.
<noah> Raman: After that, we'll be discussing a significant proposal for TAG focus on AWWW for Applications. We will start refining a proposed Table of Contents. Should be around 1:15 PM our time, so 10:15 AM your time, OK?
<jar> timbl: Being unable to squish it into the content is not the reason it's good to use a Link header.
<masinter> TimBL: Link header overrides embedded metadata even if it's present, it's more current, more authoritative.
<jar> ... e.g. the server may just know better. May have access to list of versions, etc.
<noah> Also, Raman, though it's not in the agenda yet, I'm planning to have our last session (4:15 our time) be the TAG logistics session. Scheduling future meetings and summer telcons.
An example of something medata with link header is http://www.w3.org/2007/ont/unit
<Zakim> timbl4, you wanted to say HTTP level data is sometime a first resource because it really is authoritative.
<Zakim> timbl, you wanted to talk about W3C doing vocabularies
<masinter> http://www.w3.org/TR/2009/WD-mediaont-10-20090618/
<masinter> "Ontology for Media Resource 1.0"
<jar> timbl: W3C staff is asking how much W3C should be involved in ontology development
<jar> ... provide an environment? stimulus? process? tools?
<jar> timbl: What is the level of agreement between dspace, fedora, eprints (re bib format)?
<jar> dan: ... re vcard & html5 ...
jar: As a consumer, I think it would be really nice to have some agreement on some basic vocabularies, such as in bibliographic data.
<jar> ... but it's not different from any other standardization tarpit
Noah: I have necome awrae of the tendency of the TAG to get to a state in which we have become aware of the fact that it might kinda be useful to do something.
Larry: I have an action to open up an issue, and this discussionhas been very informative.
Noah: I will need to understand what the TAG should do in this area. Shoiuld we look at whether W3C should get into ontology stndardization?
<masinter> standards provide for extensibility but also a "common base" that everyone agrees that, no matter what else they did.
<noah> LM: I will, in my framing of the issue, try to set out options for what if anything the TAG should actually do about this.
<masinter> Three issues: access, format, vocabulary
jar: I haven't been sure before about what the TAG could do, but now I feel we should have a metadata architecture. It is also something I find it very easy to justify working on as it is key to Science Commons.
<jar> & trust/authority too
Noah: Would this be useful use of TAG time?
[general positive rumblings]
RESOLUTION: We want to start work on metadata in general, including access and formats.
<scribe> ACTION: Jonathan to draft a finding on metadata architecture. [recorded in http://www.w3.org/2009/06/24-tagmem-irc]
<trackbot> Created ACTION-282 - Draft a finding on metadata architecture. [on Jonathan Rees - due 2009-07-01].
<masinter> would include working groups working on vocabularies, link access, RDF/A
<masinter> audience should
Ramin: We should know who the audience is for this, and how we are going to have an impact with the work.
<jar> raman: Who is the audience? How will we have apositive impact? make sure that's answered
Jar: I can think of a number of people who would eat this up.
<jar> action-282 due 2009-08-31
<trackbot> ACTION-282 Draft a finding on metadata architecture. due date now 2009-08-31
<ht> _Proofs and Refutations_
<ht> by Imre Lakatos
<masinter> scribenick: masinter
<Ashok> Noah: I'm being encouaged to consider the HTML5 draft.
<Ashok> ... how can we influence the draft?
<scribe> ScribeNick: Ashok
<noah> I agree with the suggestion that we should focus on how to positively impact the HTML work.
Noah: If I said I'm pessimistic, we will not have influence on HTML work, would someone push back?
<raman> calling zakim
LM: It is a good general discussion; even if we do not have influence on HTML5, it may influence other WGs.
<noah> Will dial. Note that agenda has again been revised, due to last minute change in Tim's availability. See posted agenda.
<raman> all by myself on zakim
LM: we shoud approach from POV that, if they are right, how would we modify the versioning finding?
<noah> Raman, see note above on schedule change: now discussing versioning
LM: Also possible we may have a positive effect on HTML5 itself.
JK: I agree w/Larry
<noah> TBL: We should explain that HTML 5 is using a different pattern.
TimBL: It would be OK for TAG to agree with our tag-soup conclusions
Noah: LM is talking about version identifiers
HT: Tim is also talking about version id's
<Zakim> ht, you wanted to support the proposition wrt the narrow goal
Raman: Does the exception apply also to Web Apps? Where does it end
ht: +1 to emphasize certain aspects of what Larry said. This is a narrowly scoped proposal.
... pros and cons of the space in which the decisions about version id's fall
... we will end upo with costs and benefits
... there is no single best practice... that's the point
Noah: We did some work on XML versioning
... now moving to HTML space ... specifically about version identifiers
LM: Consistently in HTML WG when general priciples are raised the questions comes back "can you justify this is a good principle"
... we need to explain why version id's are a good idea or not
Noah: Proposal --- to do a balanced analysis of pros and cons of version id's and who would be influenced by it
Dan: That's a pretty high bar but 'yeah'
<masinter> suggest removing 'balanced'
LM: As balanced as we can be
Dan: the challenge I see is to do the macroeconomic analysis well
<masinter> I think, for example, that we will need a framework for talking about versioning and APIs
Noah: I would like to do some teaching on this
... please notice these points of confusion
JR: This is interesting to me because this is a puzzle. If I learn something I would be interested in telling someone else.
... it seems valuable and seems hard.
<masinter> Ashok: Noah is looking at this from the filter of past versioning work, and that didn't work out very well. Ashok thinks this is different, more specific.
Ashok: This is different ... only for HTML and only the version id proposal.
Noah: So do we start some work in this area?
... seems like we have consensus to do so.
<johnk_> what is the role of http://www.w3.org/2001/tag/doc/versioning-html/versioning-html-20090611.html?
Noah: Larry, what steps would you propose?
LM: Yesterday I went thru the outline of the document we wrote. It would be good to go thru it again and get feedback on it and then plan what to do about the document.
Noah: We said we would work on version id's. The document title/abstract is very broad.
LM: Our success criteria shd be if we answer whether there shoud be a doctype in HTML5.
... I think we will come up with something broader.
... Look at last sentence of second para.
... I accept the discussion should be narrower
JK: The start of the doc provides context. The rest is about version id's
LM: The intro promises more than the document delivers and what we are interested in. We should edit the title.
JR: What about the other issues re. versioning?
Noah: The language versioning issue remains open.
... David Orchard will publish his doc under his own name.
... and we would go quiet about versioning for a while.
JR: Asks about other versioning issues like distributed extensibility and the attitude of WGs about extensibility
LM: Let's focus on version id's first ... and for HTML5.
(reviewing versioning document)
LM: The terminology section we talked about yesterday. There was some discussion about how to go about talking about what a language is.
... HTML5 says a language is what people use not what's written in the spec.
... this is an important distinction.
Dan: I would rather not see an upfront terminology section. I would rather define the terms in context.
<Zakim> noah, you wanted to discuss specifications vs. languages
<masinter> i think that's editorial (whether there's an up-front terminology section).
LM: Needs to say which language is being versioned
Noah: I'm not fond of this phrasing about what language is.
... language is a set of texts and what the texts mean
LM: What's missing is the distinction between language and dialects ... how languages are used.
... Languages apply to a community that agrees to speak it
... ((Discourses on languages and their implementations, an versions thereof.))
JR: I think that's very important. I was using a single word for languages that are specified and languages as they are spoken.
LM: Languages have constraints and permissions
... implementations have behavior.
Noah: Its useful to separate the spec of language from what the language itself >is<.
<masinter> i think it's important to talk about 'communities' of *implementations*
<DanC_lap> (one of the reasons I hate up-front terminology discussions is that they result in this sort of let's-discuss-everything-at-once discussions. a list of terms and their definition is the end of the game, not the beginning.)
Noah: describes Purchase Order languages
... there are different users with different uses in mind
... these could be spelled out in different specs
LM: We don't share assumptions
... communities are communities of implementations
... there are constraints and permissions exhibited by language specs, and behaviors exhibited by implementations
Noah: Example: HTML language and 2 browsers -- traditional and voice
... there will be a 3 specs: langauge spec and 2 implementation specs
<masinter> ((noah asks for distinction between spec, implementation spec, implementation))
Noah: pl. explain how you would tell that story
LM: I am separating implementation from an implementation spec. You cannot 'define' an implementation except by the implementation itself.
<johnk_> I think (but don't know) that Noah meant that there were two kinds of spec in this example - language specification, and implementation class specification.
<noah> Yes, and in particular, one should try to avoid leakage of implementation specifications into language specifications (at least most of the time)
<johnk_> implementation specification, or implementation /class/ specification?
LM: ((describes an example of implementation spec and discusses refining specs that would have a narrower domain of applicability))
... Part of issue with HTML5 is that level of specificity is detailed enough to make you wonder if it does not inappropriately specify behaviour of other agents
Noah: They would say that hidden within this is an author spec
<masinter> it isn't hidden
Noah: I am concerned about their lack of recognition of other agents
LM: The charter says to produce a spec that applies to all agents; behavior of compliant browers is specified, and other agents want to be compatible with browsers
... Calling it anything other that a technical spec of HTML would be to insult it.
<noah> Raman, if youi're curious, we're still waiting for Tim to return
<masinter> question about distinction between language specifications having constraints and permissions, while communities of language implementations have behaviors
HT: This is a useful distinction berween spec and implementation
... I was thinking that all interactions are 1 producer to one consumer. Or 1 producers and many consumers.
... rare to have many producers and 1 consumers.
<masinter> a specification is an attempt to document or propose constraints and permissions to communities which agree on behavior.
HT: in HTML very small number of consumers ... say 4
Noah: disgrees saying users are people in front of the screen
HT disagrees
<masinter> http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
<Zakim> ht, you wanted to mention the cardinality of consumers point
Noah: Argues that users are humans not browser vendors
... Assume you are right. What do we conclude from that?
HT: I want to go back and see if this understanding changing anything
LM: IE on Windon Windoes and IE on Mac etc are differents agents. So many more than 4 users
<Zakim> ht, you wanted to give way by an order of magnitude, maybe two, but not much more
HT: OK. It's in the hundereds not in the millions
<Zakim> DanC_lap, you wanted to suggest 'critical mass of the market' as a way to distinguish "4 major browsers" from the long tail of tools. The long tail can't wag the dog ;-)
Noah: Do microformats change the equation?
<masinter> level of interoperability is an important concept
LM: I will take an action to respond to feedback on this document
Noah: Start a finding?
<DanC_lap> ACTION: Larry update document on version identifiers w.r.t. Cambridge June discussion [recorded in http://www.w3.org/2009/06/24-tagmem-irc]
<trackbot> Created ACTION-283 - Update document on version identifiers w.r.t. Cambridge June discussion [on Larry Masinter - due 2009-07-01].
Noah: on version identifiers
<DanC_lap> action-283 due 24 July
<trackbot> ACTION-283 Update document on version identifiers w.r.t. Cambridge June discussion due date now 24 July
LM: Moving on with the document
... I want to get more history on doctype
Dan: I don't think DOCTYPE is an interesting design. Only design is version attribute on HTML5
<jar> jar's advice to LM: please treat consumers and producers more symmetrically. my comment "why constrain only consumer behavior" was an experiment and now i think it's better formulated as constraints (or behavior or practices) on both producer and consumer.
LM: What are in-band global version identifiers; try and postulate possible version changes that may happen for HTML 6 and a game-theoretic consequences of having the version Id's for HTML6
... cost/benefit tradeoffs
Noah: Summarizes
... we decided to move forward with this work with focus on version indicators.
JK: So we shd review doc and send comments?
LM: Yes
Noah: We added this based on yesterday's discussion
<masinter> Noah: Tim said: we have an arch for web of documents. What is the architecture of the web when you're sending and running applications locally?
<DanC_lap> scribenick: masinter
Noah: Is this something we want to bite off -- does this become a new chapter of AWWW? Does it influence the current document, etc?
... first concentrate on content. Let's imagine what we're going to do is add another section of the AWWW
Put together what a table of contents would be. From that we can debate whether this is a good focus for the TAG's work.
<DanC_lap> "Draft Standard — 24 June 2009"
<DanC_lap> -- http://www.whatwg.org/specs/web-apps/current-work/multipage/
<noah> http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
((Discussion about title and name of what we're working on))
TimBL: HTML5 is a really strong priority for TAG to look at it
... If TAG members to see things wrong with HTML5 we should say something about it. Otherwise "bad things happen because good people don't act on it"
((discussion of the 'iCalendar' issue, for example))
<noah> Updating live copy of TOC @ http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
<noah> timbl: Can we spend 1/3 of our energy on HTML, 1/3 on Web application architecture, and 1/3 on other things?
Noah: proposes we look at Web applications architecture, then come back and answer this question
... Proposed table of contents again http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
Question is whether TAG will take this on as a major work, of the same scope as AWWW?
What are the parallels to the 'regular web' and how are things different or not?
Ashok: point out HTML5 has a database interface (which he thought they had no business spelling out, thought it would be in the form of SQL calls.)
<Zakim> johnk_, you wanted to suggest we need to come up with a unified statement that encompasses the laundry list curently written
Ashok: We ought not go in and follow working group, not sure we should interfere.
jk: if I look back to the original webarch, we extracted general principles, resources & representation, we said "Use XML" and gave good practices
... I'm saying a little more: what is the unified statement we'd make about this laundry list of specifications; is there anything we can say about JavaScript and CSS and HTML5?
ht: somehow Noah's TOC document got away from the whiteboard
... i think it's important enough that it's worth trying to do it
... primary energy of those behind HTML5, people's sense of how they want to use the web and the net is a distributed application platform, but not suprisingly it's not going very well
((discussion about WebAPPS vs. HTML5))
<noah> Raman, do you want to be on the queue
ht: all we might wind up doing is try to give guidance to HTML5 for webapps arch
danc: trying to find history of calendar stuff, found offline storage
... ((discussing offline storage & webapps vs. html5))
jar: has typed in everything on the board and organized
<DanC_lap> TVR: this all made sense until we started talking about it being separate from HTML 5;
<DanC_lap> ... these are all tangled up, as Henry said
<Zakim> DanC_lap, you wanted to note HTML WG's separate WD on database API and to note http://www.w3.org/TR/2008/NOTE-offline-webapps-20080530/ and to promote "...no business..." to an
jar: when this discussion about CORS was going on, that ended when Anne came to an impasse
<Zakim> noah, you wanted to talk about HTML 5 vs. what we do
Noah: perhaps he's piling on. We have to go into this that part of our job is to influence HTML5. But we should try to set out is to set out principles and advantages in a way that people would have trouble disagreeing with.
... for example, with URI finding 'if you use a URI for everything, you'll be able to link to a URI'
... doing that when informed by HTML5 is fine.
... People have not disagreed about whether you get some advantages or disadavantages with a certain pattern, they've disagreed about whether the advantages are important.
... What's going through my head is that really undertaking this the way Tim said is a big focus for us.
... What I hear is somewhere between positive and real enthusiasm.
Raman: if you start out to be a multi-year exercise, we will fail.
Noah: how do we build something like this? Often the way we've used findings are details or summary.
... keep working on the outline, do that in the form of findings and notes.
... maybe in parallel and appoint an editor or two.
masinter: suggestion to take each of the topics and write up 'what is the question', and use that as a way of motivating discussion.
Noah: put that up as a live outline. as people discover new things
((discussion about whether it's a wiki or cvs or form))
jk: it would help if we could write up a statement that says: "web applications already exist, they are things that are delivered from a server by a client", what happens? Most of these issues revolve around mash-ups?
<noah> Tim earlier said: Can we spend 1/3 of our energy on HTML, 1/3 on Web application architecture, and 1/3 on other things?
jk: Mash-ups are an example of an area where the issues are most clear
((discussion about state and multi-parties applications between JK and TimBL))
<raman> lunch beckons. I'm off
((Discussion about offline apps vs. Comit and plumbing and issues around that.))
TimBL, JK, Noah
Noah: How much of our traditional terminology applies? E.g., web server on phones?
... Want to push back, throw out ideas for how we organize things.
... Question about this organizing findings and notes, unified document as a whole not sure
... continue working on drafts and findings we've already heard
... take a list like this (the TOC), tune it up; under each one, try to catalog what the issues, pain points, and opportunities, build up over time.
<johnk_> it would help if we could write a statement that says "web applications already exist - traditionally they have been delivered by an (HTTP) server and rendered by a (browser) client. Today, web applications often have multiple communicating parties, and the client often acts as more than a rendering agent. What are the architectural issues?"
Noah: at various times we will decide
Jar: our charter is to produce architectural recommendations, not finding
... it's been 5 years, we should be working on one
<johnk_> ((by the way, not too wedded to the statement I've made, but would like to be able to make clarifying statement of some kind for this work))
danc: building a web application, got into permission problems. cross origin was most difficult element for ordinary programmer
ht: (side note) range of conflicting responses to our message to Art. various players have responded.
Noah: how to fill in this outline? would like to wrap this section?
... will get people assigned to this
... I will come back to get the next round of work, writing down briefly a few line items with a few sentences or a paragraph.
<scribe> ACTION: jonathan to flesh out the outline with as many sentences as he can [recorded in http://www.w3.org/2009/06/24-tagmem-irc]
<trackbot> Created ACTION-284 - Flesh out the outline with as many sentences as he can [on Jonathan Rees - due 2009-07-01].
Noah: after break we will work on schedule
group picture
<DanC_lap> jar, re 1st party etc. http://www.downes.ca/post/38498
<johnk_> re: 3rd parties http://en.wiktionary.org/wiki/third_party
<jar> I had been saying "second-party metadata" meaning metadata coming from the origin (or the URI or the resource or the representation). Dan has corrected me and I will henceforth call it "first-party metadata"
reconvene
<noah> Raman, we are discussing f2f scheduling
<ht> TV, you there?
<DanC_lap> we discussed summer telcons; noah has notes
<ht> Formal proposal to move 22-24 Sept TAG to 23-25 TAG
<DanC_lap> PROPOSED: to move Sep meeting to 23-25 Sep
<ht> Amy, any reason not?
<amy> s
<ht> 22 Sept is One Web Day
<DanC_lap> so RESOLVED.
Nov 2-6 in Santa Clara TPAC
<amy> the group would have to split days between Star (not the room you're in) to Kiva (the one you're in now)
<DanC_lap> ah. I think we can deal with that, Amy
<amy> ok, if you like the room you're in, I can get you that for two of the three days
<DanC_lap> cool. thanks.
<noah> Amy, we have voted to reschedule for 23-25 Sept. Would you please move rooms.
<noah> Thank you!
<amy> ok, I confirm the rooms are moved
<amy> same basic procedure. I'll get catering, let me know if you need a bridge/phone and any parking
<amy> i can send info on nearby hotel rates (w/ the MIT rate) if you need later
<DanC_lap> ACTION: Noah make sure TPAC logistics are straight [recorded in http://www.w3.org/2009/06/24-tagmem-irc]
<trackbot> Created ACTION-285 - Make sure TPAC logistics are straight [on Noah Mendelsohn - due 2009-07-01].
<DanC_lap> LMM: HTML WG meets Thu TPAC week
<DanC_lap> action-285 due 30 July
<trackbot> ACTION-285 Make sure TPAC logistics are straight due date now 30 July
<timbl> http://www.w3.org/2009/11/TPAC/
discussion about schedule, not worth minuting
adjourn