A text-only copy of the minutes from the second day of the TAG's F2F
meeting in June, 2009 is attached.
One Rogers Street
Cambridge, MA 02142
- DRAFT -
W3C TAG Face To Face meeting
24 Jun 2009
See also: IRC log
jar, johnk, timbl, jk, noah, masinter, ht, dc
timbl, masinter, Ashok
1. Mobile Web
2. Metadata Access and Formats
3. Versioning and HTML
4. Web Arch for Applications
5. tag administration issues
* Summary of Action Items
<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
HT: Even my phone does some web, and its level is well deployed in
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
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
... 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
... As the performance increases, that dominance will rise
... Most people on the web will be mobile users talking to the coud
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
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?)
NM: For a bank, for example, most of the time I 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.
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.
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.
(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
Noah: On the iPhone, you can now use gmail when completely offline,.
All your gmail information is downloaded into local storage from the
web... but you can't get at the contact list because of the
Jonathan: (Doesn't work for me.)
Noah: So the need now is for an API for getting at the local contact
<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
... 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
<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
<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: 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
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,
Metadata Access and Formats
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.
<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):
<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
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
<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
<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
<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
<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
<masinter> ((relationship to content type sniffing?))
<masinter> ((WebDAV has protocol for managing 'metadata', doesn't
<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
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
<masinter> ((want to put in a pitch for embedded metadata))
<jar> ((embedded is always better than Link: **all other things
<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
... 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
... This is useful to just note they are coming from different
<johnk_> Making decisions about authority requires the ability for
the recipient of the data to be able to reasonably authenticate the
<noah> TBL: There are lots examples where different people are
responsible for that information. Sometimes one or the other is easy
<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
<noah> TBL: How does Henry find out that Dan has "tweeted" about
him? One answer: twitter.com sends an email saying "look who tweeted
<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 -
Noah: (Yes, archiving something and saying is is incorrect is a
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
<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
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
... 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
<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
<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
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
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
<noah> Raman, we're talking about metadata. I'll dial now.
Larry: The format is a non-current profile of RDF. It is however
... 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
<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> "Ontology for Media Resource 1.0"
<jar> timbl: W3C staff is asking how much W3C should be involved in
<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
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
<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
<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
<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
Versioning and HTML
<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
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
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
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
... 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
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
Noah: So do we start some work in this area?
... seems like we have consensus to do so.
<johnk_> what is the role of
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
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
... HTML5 says a language is what people use not what's written in
... 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
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
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
<masinter> i think it's important to talk about 'communities' of
<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
<masinter> ((noah asks for distinction between 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
<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/
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 don't understand 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
<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
<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
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
<trackbot> Created ACTION-283 - Update document on version
identifiers w.r.t. Cambridge June discussion [on Larry Masinter -
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
... we decided to move forward with this work with focus on version
JK: So we shd review doc and send comments?
Web Arch for Applications
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
<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"
((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 @
<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
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
jk: if I look back to the original webarch, we extracted general
principles, resources & representation, we said "Use XML" and gave
... I'm saying a little more: what is the unified statement we'd
make about this laundry list of specifications; is there anything we
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
danc: trying to find history of calendar stuff, found offline
... ((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
... 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
<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
((discussion about state and multi-parties applications between JK
<raman> lunch beckons. I'm off
((Discussion about offline apps vs. Comit and plumbing and issues
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
<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
Noah: at various times we will decide
Jar: our charter is to produce architectural recommendations, not
... 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
<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
<DanC_lap> jar, re 1st party etc.
<johnk_> re: 3rd parties
<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
tag administration issues
<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?
<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
<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
discussion about schedule, not worth minuting
Summary of Action Items
[NEW] 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]
[NEW] ACTION: Jonathan to draft a finding on metadata architecture.
recorded in http://www.w3.org/2009/06/24-tagmem-irc]
[NEW] ACTION: jonathan to flesh out the outline with as many
sentences as he can [recorded in
[NEW] ACTION: Larry update document on version identifiers w.r.t.
Cambridge June discussion [recorded in
[NEW] ACTION: Noah make sure TPAC logistics are straight [recorded
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.135
$Date: 2009/07/21 20:50:04 $
|Free forum by Nabble||Edit this page|