LMM: proposes that we look at comments made by an outsider to the HTML5 process

NM: link?

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"

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)

Semantics of "resources" in RFC 3986 and RFC 2616

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?