<scribe> Scribe: johnk
Date: 06 August 2009
NM: we will have a call next week, LMM to scribe
NM: Who has read the minutes of our teleconference of 23 July?
DC: will approve
... RESOLVED: minutes of 23 July 2009 are approved
JK at risk for next week's call
NM: suggestion in agenda that we co-locate Spring TAG meeting with IETF in Anaheim
LMM: that was the third of three suggestion to improve coordination between TAG and IETF
i) invite IETF to a call
ii) invite IETF notables to TPAC
iii) joint TAG/IESG/IAB meeting
^ Larry's email
NM: would you be willing to put forward in more detail suggestions about coordination between IETF/W#C before TPAC?
LMM: more overlap between IETF and W3C now than in past, so relationship is very important
... arch work in IETF group should be coordinated with arch work in W3C
NM: can you put in email ways in which I could get started on liaison with relevant IETF people/groups?
NM: (reviews agenda)
... (discusses item 7,8 on agenda)
NM: we agreed to read the specification
<masinter> pointer to assignments?
<masinter> would be useful to turn these into action items
NM: does anyone have problems with their assignments?
DC: I may have trouble meeting the goal
<DanC> ACTION: dan read HTML spec parts from http://lists.w3.org/Archives/Member/tag/2009Jul/0026.html due 30 Aug
<trackbot> Created ACTION-293 - Read HTML spec parts from http://lists.w3.org/Archives/Member/tag/2009Jul/0026.html due 30 Aug [on Dan Connolly - due 2009-08-13].
<DanC> action-293 due 30 aug
<trackbot> ACTION-293 Read HTML spec parts from http://lists.w3.org/Archives/Member/tag/2009Jul/0026.html due 30 Aug due date now 30 aug
NM: (to all) let me know if this isn't going to work for you
<masinter> ACTION: Larry read HTML spec parts from http://lists.w3.org/Archives/Member/tag/2009Jul/0026.html due 30 Aug
<trackbot> Created ACTION-294 - Read HTML spec parts from http://lists.w3.org/Archives/Member/tag/2009Jul/0026.html due 30 Aug [on Larry Masinter - due 2009-08-13].
NM: close action 288 on Henry to divvy up sections of HTML spec.
(and does so via web interface)
LMM: proposes that we look at comments made by an outsider to the HTML5 process
LMM: working on it
... spent time working on the versioning document, and felt as if I made a breakthrough in my thinking
... part of the trouble we've had is about the confusion between language as specified vs. language as spoken
... role of version indicators is in... [scribe missed the last part]
... every spec specifies at least two languages - an appropriate, correct conforming utterance, and what a receiver ought to do to make a correct interpretation
... is indicator used to indicate the implemented language, or the specified version?
... given that background, role of inline version indicator is to show which conservative language was intended
... receiver might ignore it, but indicator is useful in building a _conservative_ receiver, and also in case where liberal receiver might want to distinguish between incompatible language variants
<Zakim> noah, you wanted to talk about two views of version identifiers
NM: what problem are we solving with version indicators?
... point you're making is interesting, robustness principle is interesting but not the common case
... common case is when receiver and producer expect the same language variant
... author may know that element means the same thing in multiple versions of the language
... references his TAG blog entry and examples given there
<Zakim> ht, you wanted to concur, but qualify the assertion about authors and VIs
HT: when author puts an indicator in, they _mean_ the conservative interpretation
... clear that all authors have not thought that through
NM: what do you mean by conservative?
HT: [scribe missed the answer]
LMM: W3C is in the business of documenting what the specified language is
... every standard has the specified language, and then specifications of implementations
NM: not necessarily asymmetry between producer and consumer
... producer will know what a consumer will do under all circumstances to point of when they agree there is an error condition
<Zakim> ht2, you wanted to ask about walled gardens (again)
LMM: HTML5 gives implementation advice as well as specifying the language
HT: most pushback against version indicators has been that they lead to walled gardens
LMM: one argument is that DOCTYPE is useless - under what situations would DOCTYPE be useful?
<Zakim> noah, you wanted to talk about terminology
LMM: [scribe: phone hiccups giving me fits today]
NM: suggest that both language is a set of text made by the producer, and language is also something to do with the interpretation
<masinter> I've been trying to be clear about "language" that doesn't agree with what NM is saying
NM: what we tell authors to write is clearly the language. I would claim that there is a second language, which is what is interpreted by the consumer
<masinter> and "Language as a set of strings" isn't a good definition
<Zakim> DanC, you wanted to suggest putting DOCTYPE aside in favor of an attribute
NM: call one the "producer language", the other the "consumer language"
DC: DOCTYPE has issues in rendering
NM: that doesn't make it a different language?
DC: you will get counter-arguments which are orthogonal to versioning
NM: why's that - quirks-mode rendering gives essentially a second language?
LMM: suggestion is that each time someone issues a specification document, they rev the version indicator
NM: 150 versions of a spec a year, which version(s) should I put in my instances?
LMM: consumer will mostly ignore then anyway
NM: then why put it there at all?
LMM: wanted to redefine language as "not a set of strings"
NM: undoes work we did in TAG
DC: we said "set of strings and meanings"
LMM: I don't think it undoes what we've already done
... distinction between things we call languages is really important
NM: interpreted language is a language
NM: geopriv vs. Geolocation?
LMM: Is the TAG going to be proactive about reviewing the geo-location work?
... if so, we should invite members of the geopriv WG
NM: what is the timing on this?
... last call
... anyone have suggestions here?
DC: inviting chairs/editors from both committees might be interesting
NM: what is the substantive issue here
<DanC> one pretty representative technical thread: http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/thread.html#msg98
LMM: current W3C activity provides no such in-band explicit mechanism
NM: would all agree on this as a summary of the issue?
DC: should privacy indications from UA or provider of the location information?
NM: is this the issue?
[scribe break due to person at door]
NM: next steps though?
what actually is the _architectural_ issue?
LMM: propose that we tell geo-location people we will review to discover whether IETF group got a sufficient response
... fine if we simply resolve to review the geo-location spec.
NM: don't see the value at the moment in making such a resolution
... I am happy to facilitate liaison between TAG and IETF on this specific matter
LMM: request was made already
... prefer not to limit our freedom at this point, but open to some specific comment
DC: Larry offered to do something , we should either ask him to undo his offer, or do something to indicate Larry met his commitment
NM: no problem with what he asked, just as to what, if any, next steps should be
<DanC> ACTION: DanC to monitor geolocation response to IETF GEOPRIV comments on last call and report to the TAG
<trackbot> Created ACTION-295 - Monitor geolocation response to IETF GEOPRIV comments on last call and report to the TAG [on Dan Connolly - due 2009-08-13].
<trackbot> ACTION-254 Send email to www-tag announcing issue-63 notes added
<trackbot> ACTION-254 Send email to www-tag announcing issue-63 closed
LMM: looking for comments on that email
NM: first goal is to review this email framing the discussion on metadata
LMM: tried to separate 4 items which have inter-dependencies
* Metadata model: what is the "data model" for typical metadata applications - the datatypes of the endpoints
* Metadata serialization: how can metadata be encoded in a representation system, be it RDF or something else
* Metadata vocabularies: what are appropriate vocabularies for describing various media objects and network services? What is the process by which new vocabularies can or should be developed, described, extended or changed?
* Metadata linking: What are the various ways in which metadata can be associated with "data" or other resources? Link relationships, protocol elements, mechanisms for embedding metadata in various kinds of data.
LMM: was trying to create general categories
NM: we agree to have two issues - 63 being on the metadata itself, 62 being on the linking part
LMM: Issue 62 is too narrowly defined
NM: if it doesn't fit in 62, then it's 63.... or
... broaden 62 to be about metadata access
LMM: reason for putting these in the same issue is the interdependencies
NM: would be good thing to update the descriptions of the two issues to explain the relationship between them
LMM: willing to update 63 to point out that 62 is a narrow part of the general issue
<masinter> relationship explained in email above
action on larry to update ISSUE-62 and ISSUE-63 to reference each other
<trackbot> Sorry, couldn't find user - on
action larry update ISSUE-62 and ISSUE-63 to reference each other
<trackbot> Created ACTION-296 - update ISSUE-62 and ISSUE-63 to reference each other [on Larry Masinter - due 2009-08-13].
NM: (return to action review)
NM: he raises the question of consistency between HTTPbis and RFC 3986 regarding the term "resource"
LMM: this was discussed on HTTP maillist, those sections of HTTPbis are being updated, and we should wait to review that text
<masinter> i think i've read them all
HT: has been lots of discussion, and don't think we can walk away from it
<masinter> I've proposed a task force which focuses on updating the documents
NM: is it enough to wait until we see text from HTTPbis?
<DanC> (I tuned out a long time ago. too philosophical for me.)
<Zakim> ht, you wanted to point to the scale of the discussion
NM: OK, let's wait for the HTTPbis work to appear
DC: Larry suggested a task force
DC (to LMM): Are you OK to wait?
LMM: idea was to charter a taskforce to come up with specific wording changes, and taskforce should wait until the updated HTTPbis draft appears
... rather than handling as a TAG issue ourselves, we actually bring in the relevant people to work on any specific wording changes
DC: might help to say that we're going to wait for the updated HTTPbis draft?
NM: I could send a note saying that we have decided to wait for the redraft that we know to be coming?
LMM: mnot has requested a separate list is created for these discussions
NM: would suggest that email aimed at getting the TAGs interest should be sent to www-tag - we cannot promise to review other mailing lists
... is there anything more to do here?
NM: should we add to next week's agenda?
LMM: put it off
HT: people interested in extensibility should look at the thread at the above link
<masinter> looks really interesting
NM: can you (HT) send email to TAG inviting discussion "over there"?