- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 16 Oct 2009 16:36:12 -0400
- To: www-tag@w3.org, public-tag-announce@w3.org
Unapproved draft minutes from the F2F meeting held by the TAG from Sept.
23-25 2009 are now available. Links to records of individual discussions
are available from an updated copy of the agenda page [1], and for most
readers these will be the easiest way to find items of interests. The
agenda links are into the complete records for the respective days [2-4].
Text-only copies of the minutes are also appended to this email. I expect
that the TAG will consider approving these as a true record during our
teleconference on 22 October. Thank you.
Noah
[1] http://www.w3.org/2001/tag/2009/09/23-agenda
[2] http://www.w3.org/2001/tag/2009/09/23-minutes
[3] http://www.w3.org/2001/tag/2009/09/24-minutes
[4] http://www.w3.org/2001/tag/2009/09/25-minutes
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG Sep 2009 meeting in Cambridge, MA
23 Sep 2009
[2]Agenda
[2] http://www.w3.org/2001/tag/2009/09/23-agenda.html
See also: [3]IRC log
[3] http://www.w3.org/2009/09/23-tagmem-irc
Attendees
Present
DanC, TimBL, ht, jar, jkemp, lmm, noahm, Ashok
Regrets
TVR
Chair
Noah Mendelsohn
Scribe
John Kemp, Larry Masinter
Contents
* [4]Topics
1. [5]Convene, Review Agenda
2. [6]HTML, collecting issues
3. [7]references to versioned specifications (HTML 5 review
topic #15)
4. [8]Architecture of Web Applications
5. [9]HTML issue collection, cont
6. [10]document conformance vs. user agent conformance
requirements (#13)
7. [11]discussion of work on webapis
8. [12]wrap up for the day (agenda review)
* [13]Summary of Action Items
_________________________________________________________
Convene, Review Agenda
<jkemp> scribe: John Kemp
<jkemp> scribenick: jkemp
nm: (reviews "review goals" + agenda)
... discuss HTML5, and what (if any) feedback we want to give to WG
... review and make progress on items agreed at last F2F
... discuss TPAC logistics
... TPAC program committee wants to organize a session on
"decentralized extensibility" and has asked me for help in framing
the session
... not limited to the sessions and goals listed
ht: would like to keep slot on naming
lmm: would like to talk about IRIs
nm: (review each slot)
HTML, collecting issues
nm: notes the relatively new HTML 5 "authoring specification"
nm solicits HTML 5 spec issues to discuss; builds a list:
[14]http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt
[14] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt
lmm: redefinition of text/html MIME type is one issue - would help
to have common understanding on use of MIME types
... issue of error handling came up in a specific URI parsing case
... a lot of these error handling questions reduce to "what is the
role of a standard or specification"?
tbl: you want to discuss whether the error handling is defined in
the specification?
lmm: (roughly) yes
<masinter> how it is defined
nm: reviews JK issues
[15]http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html
[15] http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html
jar: HTML5 has some innovations in how the specification has been
developed
... to what affect does W3C want to carry through some of these?
nm: and use use-cases to illustrate where particular innovations
work and don't work
lmm: problem that arises when normative algorithm is used to give
constraints
... instead of giving invariants which would be exhibited by
applying an (or different) algorithm(s)
ht: impact of script and document.write
danc: drag and drop and relationship to bibtex, vcard
am: commented about how they talk about datatypes - using prose
instead of BNF
lmm: conformance requirements which are not testable
ht: my related point is that there is a notion in the HTML spec is
that document conformance and UA conformance are decoupled
... not sure that this is achieved
... and whether the goal is a good one
<noahm> What I've recorded is: "The spec seems to decouple "user
agent conformance" and "document conformance". Stipulate that's a
good goal. There's a question of whether the spec. actually achieves
this. Was it a good goal in the first place?"
lmm: outline section has no exhibited behaviour in other parts of
the spec.
jar: OWL spec. has this issue too
ht: XML schema too
... W3C-wide issue about references to other specifications, also
exhibited in HTML
... don't follow guidelines suggested by Sperberg-McQueen
... MUST support at least version X, MAY support version Y, for
example
<DanC_lap> (the References section of the HTML 5 spec is fairly new;
I took a look at it, and I think it does a reasonable job on the
versioned specs issue)
nm: difference between "you've got a buggy processor" and "you've
got a processor that supports a version we haven't seen"
lmm: seems to be some assumption that a WG will remain active for
the indefinite future to update the specification as refs change,
for example
ht: have we decided about use of the term URL?
... and the 'ping' attribute?
<DanC_lap> hmm... no Zakim... how about RRSAgent? nope... jkemp,
note w3.org hasn't logged the proceedings so far
lmm: the "willful violations" sections - charset override in
particular
<Zakim> DanC_lap, you wanted to add registries to the list: rel
values in whatwg wiki, Public Suffix List from Mozilla
ht: was assigned a section about scripting
... execution model is opaque to me - can we discuss?
lmm: several examples in mind - the general issue is about
applicability of the Web
... public Web vs. private Web (intranets et al) vs. use of Web
components for things "other than the Web"
<DanC_lap> (yeah... this "only the public web matters" position
seems iffy to me. I tried to blog about it, but the comments suggest
the point didn't get across well.)
lmm: public Web split between "crawlable" vs. that which requires
authentication
... applicability of <canvas> in environments such as email
jar: javascript URI scheme is in the spec. but not registered
nm: is your issue only about registration?
jar: if done, it should be done properly
<noahm> My initial list of issues was sent to the TAG here:
[16]http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html
[16] http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html
<timbl> paving cowpaths Having spent quite some time in a country
where the roads are in fact paved cowpaths, ... I know how twisted a
road you can end up with :)
...[17]http://www.theotherpages.org/poems/chester1.html#2
[17] http://www.theotherpages.org/poems/chester1.html#2
nm: link rel issue: spec calls for processing to continue in a case
that they say is "not allowed"
<DanC_lap> (I thought we dispatched with this one ("rel attribute
must... if rel is absent..."). editor ack'd as bug and fixed it.)
ht: this says that the "document is not conforming", but tells the
UA what to do in that situation
nm: document.write cannot be used with XML serialization
... I have an XML DB to manage my HTML, and can serialize as XML,
but also want to use document.write
lmm: execution toolchain - content not written only by people
writing HTML (tools are often XML-based)
... and use-cases that led XHTML WG to do modularization
... being able to subset the specification was a requirement
nm: content sniffing?
ht: IETF has taken this on
lmm: would still like to talk about this in relation to the use of
MIME types
... register a MIME type to allow sender to tell recipient what
sender means
... and... division of responsibility between W3C, IETF and also WGs
in W3C
... Origin header, content type sniffing, URI schemes are examples
nm: would like to mention issue of inconsistent (in)formality of
parts of the spec. - borderline editorial
am: some of these things are bugs, others are "meta" issues on the
whole spec.
nm: anything can be reported individually to the WG
lmm: which of these issues are we willing to commit to as a group?
nm: I feel obligation to discuss things we think are important
<noahm> Larry has expressed the concern that the HTML draft is, in
some cases, intentionally provocative, e.g. the statement that "A
DOCTYPE is a mostly useless, but required, header." There is a
perception that this is disruptive.
<noahm> [18]http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt
[18] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt
<noahm> [19]http://www.w3.org/2001/tag/2009/09/htmlissues.pdf
[19] http://www.w3.org/2001/tag/2009/09/htmlissues.pdf
nm: identify 5 things from the above list to discuss first
... everyone gets 10 votes, can assign multiple votes to one issue,
don't have to use all votes
<DanC_lap> hmm... 4+5 cluster, 7, 11, 15+20 cluster, 25. 26, 28
<DanC_lap> hmm... 4+5 cluster, 7, 11, 15+20 cluster, 25. 26, 28, 31
<timbl> Tim: 5: 4; 7:3; 11:2; 12:1
<masinter> 1,1,3,6,10,13,19,25,28,31
<jar> jar: 1,3,4,7,10,13,27,28,30
(group voting on issues as listed in
[20]http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt)
[20] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt)
<DanC_lap> 3 on 15 (+20), 2 on 25, 2 on 26, 28, 31 (revision after
realizing there's more than one choice per issue)
4,7,15,16,20,25,26,28
issues 7,13,15 get the most votes
references to versioned specifications (HTML 5 review topic #15)
dc: when you link to a versioned spec. you are delegating authority
to some other spec.
... link to a static spec. it's like loading a library
ht: there is a difference between "you must use the latest" and "you
must use some version either this dated one, or later"
dc: 2 instances in HTML - allowed rel values specified to be in
WHATWG wiki
... second is mozilla decided to create a public suffix list (.com,
.co.uk etc.)
tbl: if you're looking for the legal owner of the URI go to this
list
<masinter> [21]http://dev.w3.org/html5/spec/Overview.html has
reference [PSL]
[21] http://dev.w3.org/html5/spec/Overview.html
tbl: so that delegation of authority is clear
<masinter> search for "Public Suffix List"
<masinter> 2.4.9 Reversed DNS identifiers : #
<masinter> Check that the end of the resulting string matches a
suffix in the Public Suffix List, and that there is at least one
domain label before the matching substring. If it does not, or if
there is not, then the string is not valid; abort these steps. [PSL]
tbl: below that, delegation is not open
dc: browser can then tell you "who owns the page"
... I think this shows up in the origin work
... feedback from IETF was "don't do that"
<masinter> "6.4.1 Relaxing the same-origin restriction"
lmm: (inserting into IRC some refs to "informal registries")
... spec. incorporates by value in some places - eg. vcard - one
kind of versioning
... also applies to HTML use of URIs
... then, the case of a normative ref to another specification
<ht>
[22]http://www.whatwg.org/specs/web-apps/current-work/#references
[22] http://www.whatwg.org/specs/web-apps/current-work/#references
ht: worth nothing that when we reviewed the spec, there was no
references section
<DanC_lap> (interesting... the public suffix list seems to be used
in the reverse domain label stuff in the microdata stuff)
<DanC_lap> (and only there. never mind what I said about origin and
javascript security boundaries.)
ht: refs are, for example, undated
<masinter> danc: that's only in one version
ht: URIs are undated, but reference itself has a date
... what happens when newer versions come out?
nm: so you're saying that the ref is dated, however the URI links to
the "latest" version?
ht: yes
<jar> the hyperlinks (not visible in printed version) are
non-normative, I hope?
<DanC_lap> recent discussion suggests printed versions are not
considered usable by implementors; so in effect, the links _are_
normative; i.e. they impact interoperability. (see msg from maciej.)
<DanC_lap> (darn; can't confirm from archives re printed versions)
nm: what do I need to do to see if my user-agent is conformant or
not?
... in cases like this, where references are unclear, that
conformance is also unclear
... comment might be that this is ambiguous and should be clarified
<jar> in the [XMLBASE] case the printed text says one thing, while
the URI says something else
<Zakim> noahm, you wanted to talk about clarity of spec language and
conformance
<ht> Here's my recommended text: Extensible Markup Language (XML)
1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and
E. Maler, Editors. World Wide Web Consortium, 10 February 1998,
revised 16 August 2006. The edition cited
([23]http://www.w3.org/TR/2006/REC-xml-20060816) was the one current
at the date of publication of this specification. The latest version
of XML 1.0 is available at [24]http://www.w3.org/TR/xml/.
Implementations may follow the edition cited an
[23] http://www.w3.org/TR/2006/REC-xml-20060816)
[24] http://www.w3.org/TR/xml/.
am: reiterates Larry's point about copying text from another spec.
(ie. vCard) and that this copy came from some dated version
... should not copy text, but reference
lmm: if underlying assumption is that WG stays active, then such
things don't necessarily matter
nm: but vague references are a problem separate from that
... for any given version of HTML can you answer the question "what
is conformant"?
lmm: answer is you read the latest HTML5 spec. and take the latest
version of every ref'd spec.
ht: (points to his prose above)
<ht> d/or any later edition(s); it is implementation-defined which
editions are supported by an implementation.
<masinter> [25]http://krijnhoetmer.nl/irc-logs/whatwg/20090920#l-219
[25] http://krijnhoetmer.nl/irc-logs/whatwg/20090920#l-219
ht: this guideline refers to W3C policy of versions vs. editions
... W3C has a strict guideline on "what is an edition"
... changes between editions are unlikely to invalidate their use
<Zakim> ht, you wanted to mention edition vs. version
<DanC_lap> ("W3C has a very strict definition of edition" yeah...
well... sorta... except we change it sometimes. :-/)
ht: more you understand about what revisions are possible, easier it
is to write things such as the above
... have to take account of the authors/documents you are referring
to
... in order to do this
jar: these specs. have contractual nature, and if you can't describe
the contract, there can be problems
... and at least you need clarity
... and decide is this what W3C should do?
<Zakim> jar, you wanted to mention w3c's brand as a standardization
org, e.g. to us govt
<Zakim> masinter, you wanted to ask Noah to say what he thinks is
ambiguous
lmm: if you presume WG continues beyond life of individual spec. and
that you'll update the spec. quickly
LM: There's a belief, I think, that efforts to guess in advance the
kind of changes that will later be needed have not done well.
Therefore, not worth the time.
lmm: trying to allow for distributed extensibility and clear
references is not worth the time
... because we have failed in the past
... architectural separation between implementation guide describing
current behaviour vs. long-term specs. that can be referenced
... would be a good place to start
ht: envisaging role of HTML WG being constant maintenance of
compatibility between browser implementations is a valuable vision
for the future
... and have a longer cycle for the HTML language
nm: 1 thing HTML WG does is to maintain the language - references
from that to external specifications should be made clearly, without
needing to revise the spec.
... as a second activity, recognize the documentation of
implementation interop as being important
lmm: WHATWG started as "how to build applications using Web
technologies"
... my definition of a platform is a set of interfaces
... WHATWG platform has a set of interfaces including JS, HTML etc.
... HTML5 combines the def 'n of the HTML language with the def'n of
the DOM API, Origin interface et al
... because the original goal was to define a platform, not one
interface
ht: should give some thought as to why this might not be seen as an
issue
<ht> What I said in response to TBL was I would recommend we request
that the HTML WG consider the matter of dated/updating references,
suggest that they follow MSM guidelines for W3C Specs, and consider
"or successors" for IETF refs, on a case-by-case basis
nm: having an always-on WG prevents a problem where you have a ref'd
successor spec. which is no longer compatible
lmm: separate the spec. into two parts - one of which is intended to
be stable, and which has stable refs
... and a second part with makes normative ref to the stable specs.
<Zakim> jkemp, you wanted to ask would it be appropriate to i) ask
that WG follows W3C practice on refs to W3 specs and ii) ask a
question to WG about the clarity of their references,
JK: As Tim suggested, why can't we go to HTML WG and say "here is
the W3C policy for referencing W3C specs", and if there's an IETF
policy for RFCs, etc.
DC: But there is no W3C policy, there's suggestions from Henry and
Michael Sperberg-McQueen
JK: Well then follow that.
... Beyond that specific advice, we can make suggestions about
general approaches.
<ht> The larger issue is about implementation coherence vs. language
specification and the impact on that division of the 'always on'
idea
tbl: challenge the always-on WG - when the spec. goes out it has to
say more than "this is the list of systems you must support"
<ht> We should be trying to understand what the best steady-state
will look like
scribe missed Tim's point
lmm: challenges johnk's point about giving the WG specific guidance
on writing references
... and whether that would be useful given the always-on assumption
nm: we either have to tell the HTML WG something compelling or say
something compelling to the wider community
ht: what do we envisage as a viable stead-state situation?
... right now we're in anomalous situation, but once we're caught
up, what should the steady state look like?
... along the lines of "we've got this story about implementations
work, and when they want to change that, because it works so well,
they'll come to us, and all the impls will change"
... so because we have this ongoing process, spec. changes are easy
tbl: but that doesn't work if you don't signal the kind of changes
that are likely
... implementations already rolled out /won't/ change
<jar> wondering what the purpose of specs, or this spec in
particular is. the fact (phenomenon) of a spec is to give a name
(e.g. HTML5) to a big pile of words. what consequences does this
have... uses of the spec (in pieces of writings) are various
nm: variety of refs here, please clarify - eg. difference between
dated ref and undated URI
<DanC_lap> (I'm listening for a particularly harmful incidence of
this "unclear references" issue. Haven't heard one yet.)
nm: be clear what your policy on references is - to ensure that
majority of readers come to same conclusion
... TAG believes there is value in signaling to community what kinds
of extensibility are possible
... as Tim said, people structure implementations along the axes of
extensibility
... please look for those - is it your intention to support properly
new versions of unicode, new image types etc. (these are just
examples)
lmm: how we define what Web technology is, is an architectural issue
for the Web
... and we should work out this framework
ht: consensus about references seems clear
... but the larger issue is something unclear, and I largely agree
with Larry that we should continue to work on that issue
danc: don't agree with the narrow (references) issue
ht: XML reference not clear
danc: relationship to XML is noted elsewhere in the spec.
(paragraph 2.2.1 XML)
nm: note danc's objection to the specific references issue
ACTION ht to draft text on writing references
<trackbot> Created ACTION-303 - Draft text on writing references [on
Henry S. Thompson - due 2009-09-30].
ACTION masinter to draft summary of the larger issue
<trackbot> Created ACTION-304 - Draft summary of the larger issue
[on Larry Masinter - due 2009-09-30].
break...
Architecture of Web Applications
<noahm> scribe: Larry Masinter
<noahm> scribenick: masinter
nm: have not committed to form of work in this area: finding, new
volume, or what
<noahm> Jonathan's revised version:
[26]http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921
[26] http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921
note Jonathan not back from break
nm: suggest review against previous outline since structure seems
significantly different
jk: what is the relationship of these to AWWW? Is this a new volume?
am: might not be new volume, might be addition
nm: we tell a story in AWWW about what it means for a URI to connect
to a resource, Raman's document tells another story about what Ajax
applications do. I would like to link these stories.
... Jonathan's outline looks like a computer science slicing of the
story and issues.
ht: the original list was disorganized, we asked JAR to organize it,
he did, are you saying you don't like his organization?
nm: JAR's outline... I don't see much about URIs, resources, etc.
jk: having looked at Device APIs and .... I think there is some
linking or connection that isn't evident
tbl: Historically TAG made a mistake of trying to describe web
services as part of web architecture, but it was different, they're
different patterns
... basically though they're not the same architecture
tbl, jk: we're documenting something that's completely different
nm: the use case i have in mind... (showing google maps, zooming
around): what's going on with URIs? URI i typed in was
maps.google.com; when I click on it, the client-side application
will pop up a URI which I can copy, and then put into another
browser, and get another document which is the map for the point i
clicked on in the first map
... this is an interesting story, all of the URIs are served by
Google
tbl: when we did the original AWWW it was very spotty, we focused on
places where people didn't understand. Are there areas here where
people don't get it?
nm: most places where people get confused in web applications are
things like things that Raman wrote about
... discussion about permalink meme ...
am: if I clicked ..??... and did ?? would I get the same URI?
tbl, nm: generally, if I do the same thing, I get the same URL
tbl: ... something about interoperability of google maps & yahoo
maps ...
nm: a lot of people ask me about designing Ajax apps, and when I
tell them that, they go "Really?"
ht: in practice, this is closer to Raman's stuff
... you're saying that in practice that's the same, in principle
...it could have been done server-side...
jk: two interesting things: the server is delegating to the client
the authority to mint URIs that means something. There is a resource
authority at Google. Resource authorities author the space of URIs
am: when we start talking about devices, we'll also talk about URIs
for device state
nm: (highlights JAR document "Application State" first two bollets
on "What is state? Where is the state?"
ht: whether google maps is stateless: you can't tell from the
outside
nm: if I mail you a URI, you'll get the same document. If there were
cookies you'd get "session 12? What's that?"
tbl: it's a browser problem you can't put the permalink URI into the
address bar
... it's a trust issue, the browser should be able to make permalink
ht: it should always be the case that the address bar tells you what
you're looking at
jk: in many cases you can't bookmark things, and user's expect it
tbl: there's a lot of functionality that (appears to) hangs off the
address bar (dragging the icon, copying into email)
nm: going back and forward (demo of google maps) using the browser
back button, the URI doesn't change but the view changes. This is a
strange bit of business compared to what we wrote on AWWW
... pushback on the idea that these are separate story. These look
like documents, they should be relevant to AWWW, not be a separate
story.
am: add stuff to AWWW, not write a separate volume
nm: we're not much further than we were in june, i'm disappointed,
where does TAG want to go
tbl: I think pushing on HTML5 is higher priority than this
nm: HTML5 might not take up the whole focus
... discussion of scheduling ...
... discussion of Raman's position ....
ht: rather than optimizing the table of contents (disagreement that
what's people are doing) -- we got one more level of detail out of
Jonathan
lm: i suggest as a concrete action that we review and accept this
outline as our framework for AWWW volume 2, we accept the action of
updating AWWW volume 1 which can make reference to volume 2, and we
push the scheduling of this work to really fire up later
jk: want to see what the group wants to do on webapis
... discussion of scheduling future discussion on this topic ...
... I've written a document which explores the examples in 'old
school' API vs. new WebAPI....
... my document may bear on web architecture, jonathan's outline
nm: propose wrapping this up for now
lm: let JAR go over his outline when he gets back
HTML issue collection, cont
ht: XPath and XSLT changes in HTML are issues
am: yes.
document conformance vs. user agent conformance requirements (#13)
ht: There are bunch of MUSTs in the document, some of these apply to
documents and some apply to user agents. wherever there is a MUST
that applies to documents, there's a corresponding MUST that applies
to user agents as to what a user agent should do in such cases.
... is this a reasonable assumption?
tbl: specs generally specify protocols. "If you implement according
to the spec, then you get this benefit", and generally there's a
link between the implementaiton of the spec and the benefit
... most specs leave out the proof that links the "if you implement
this" to the "you get the following benefit"
... when one of the things you have to say is that this works on all
documents, and works on all extensions, you're right, you can show
that it's true that when there's a MUST in the document there should
be an equivalent MUST
ht: this is a challenging standard to hold the spec to
tbl: it's never been done before
ht: my prejudice is: gee it would be so much easier if I had spec A
and spec B, it would better. In my experience, having these
intertwined makes it much harder to review. I've worked through 3-4
examples of this.
... example binary values, x=yes or just writing x, x=no or writing
nothing ...
... the specifcations of what you can put in your documents and what
you do, it is hopelessly entangled, spread out in multiple documents
nm: it's possible it's spread out for other reasons
... what is the reason why it is spread out?
ht: there is language in chapter 2 section about binary attributes
which is actually language about agents. When you're looking at
chapter 9 about user agents is back in chapter 2 that you might
think you only needed to look at.
... one of the things i discovered is that browsers don't strip
white space from NM tokens. in SGML and XML white space is stripped
... simple example is the type attribute link
... ... oh i need one that is enumerated ...
... halign is either left, right or center. In xhtml you can write
halign="<newline>left" and that's fine
... in sgml it's fine. HTML4 spec says browsers MAY do whitespace
normalization. HTML5 says they must not.
... this is an example where the obvious error recovery is not
mandated in HTML5 because browsers don't implement this
... HTML5 recognizes attributes that have enumerated values
nm: if you take some of the cases where you're worried about the
treatment of errors, but here's what I want you to do... I want you
to establish a clearer convention, to separate out error recovery
logic
... would that help?
ht: it would be a good thing but it would make the spec longer and
more accessibility
nm: do you think it's the right direction to look at?
ht: there's a mixture already .... example where something clarified
was for user agents and not for documents
... discussion was link rel
<masinter_> "implementor advice" are things that don't belong in the
authoring spec
ht: discussion of distinction between specific "user agent" and
"html consumer", and DOM builder, and position about all HTML
interpreters should build a DOM
... i have this perl script that finds attributes in XML. HTML
position is everyone should work in terms of the DOM
nm: is it legitimate... to build a tool, where are the rules for a
strict parser
nm, jk: html5 doesn't specify which bits of the parser
implementation are necessary to build a parser that will only accept
correct documents?
scribe: henry looking for example ...
lm: gives example of error recovery for invalid URI characters
either signalling an error or generating illegal domain...
nm: when scripting is involved, the DOM isn't advisory, there has to
be a DOM
... HTML5 is fundamentally a script-enabled version of HTML, but
because of things like onload, if you're in a script enabled parser,
if you just load a document and run the script, the only normative
definition is when there is a DOM
jk: isn't this similar to XSLT or anogous wher eyou have X? and Y?
nm: I think the way to think about the HTML dom is that there is no
Z?, there is no static W?
... because you can inject script, can't have a clean model
lm: is there a place for HTML without document.write?
ht: it's not enabled in XHTML
nm: I think this comes from a misapprehension that XHTML would use
an off-the-shelf ....
... discussion of what else would have to be restricted to make a
simpler spec ...
tbl: different times when you can use document.write, and some
places where this causes different problems ...
nm: innerHTML is much less of a problem
<timbl> innerHTML()
nm: some of the approaches we're tempted to recommend for error
recovery don't work for things like document.write
(break)
reconvene
nm: is there a kernel of a TAG comment to the working group in an
area like this? What would it be?
lm: suggests having IRC chats with HTML-WG / WhatWG
ht: if we can craft an issue and have a consensus position, we send
a comment by email, and accept the result
... on the other hand, for example, the "always on" point, and how
much the structure and rhetoric of the spec depends on that, that
would be a topic for discussion
... a call, a joint session in santa clara
... IRC has the same drawbacks as a meeting
ACTION Noah to schedule time at TPAC for joint session with HTML WG
<trackbot> Created ACTION-305 - Schedule time at TPAC for joint
session with HTML WG [on Noah Mendelsohn - due 2009-09-30].
nm: what do we do about 3 on "error handling"
ht: html5 spec is clear about enumerated values. it is also clear
that there is a correspondence of properties of dom nodes, what
happens if i write input something??=banana, i can't find out what
happens
... the correspondence between document conformance and error
recovery isn't not clear
... having told that detailed story, the higher level story is ...
what about a question of the form, "please make explicit connections
between document conformance and error recovery which user agents"
nm: the form of our feedback would be that someone would draft
something?
ht: i just asked on public-html-comments, if the answer was there
was a bug
s/something??/disabled/
<ht> s/isn't not clear/isn't clear/
<ht> s/agents"/agents must carry out for non-conformant documents"/
nm: tasking to frame an issue is better
discussion of work on webapis
review of JK document
[27]http://www.w3.org/2001/tag/2009/09/apis-on-the-web.html
[27] http://www.w3.org/2001/tag/2009/09/apis-on-the-web.html
lm: i see the cases, think i understand the examples enough, what is
the differences
ht: what is window.navigator
jk: took this example out of geolocation spec
nm: the operating system decides when it has interesting information
ht: example should include numeric parameter of amount of rainfall
... discussion of example and whether there is two or one web page
...
... discussion of cars as rain guages ...
<timbl> meteo = rdf.load(NadiasMeteo); rain=meto.the(NadiasSensor,
rainfall)
ht: URIs being minted by client ... discussion of resources and URIs
in the two examples ...
<timbl> or kb.looup(NadiasSensor); rain=meto.the(NadiasSensor,
rainfall)
nm: how am I going to implement this?
... if you're using web infrastructure use the terminology of web
... geolocation draft ... does the TAG want to make a recommendation
about that draft on the use of URIs for this?
ht: Why does it make sense to think that any device that have state
that is useful for web applications should give IP addresses to
them?
lm: could we suggest that, in the design pattern where client sends
request to server, gets back content which interacts with local
state, uses that state to customize information, and then presents
information to the user based on state, that the information used
(or the state used) should be serializable?
... trying to get back to the permalink idea
... or that google maps & yahoo maps might interoperate?
... trying to see if there's a distinction between "geographic
location" and accelerometer
<jkemp> [28]http://phonegap.pbworks.com/JavaScript-API shows an
accelerometer JS API, for example
[28] http://phonegap.pbworks.com/JavaScript-API
nm: maybe standardizing way temperature is embedded in a URI or
query string ... seems funny
... does this need to be standardized?
... discouraged metadata in URIs? Lattitude & Logitude
am: what about this case?
nm: what resolution? What privacy and security issues?
<timbl> [29]http://www.w3.org/2009/09/Nadia/meteo#sensor
[29] http://www.w3.org/2009/09/Nadia/meteo#sensor
lm: question about extensibility of GeoLocation to civic location
nm: this is following to the letter the guidelines for javascript
APIs
lm: where are the guidelines for writing extensible API
specifications?
... discussion of whether TAG should give guidelines ....
<jkemp>
[30]http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.htm
l
[30]
http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html
nm: what are our priorities? suggestion was made that it was new.
not like device stuff is first example? Should the tag be looking at
or saying interesting things about this?
am: what would we update in the architecture?
<jkemp> * Scripted APIs, as currently specified are possibly not
self-describing (and one might not be able to "follow one's nose" to
access data exposed in this way)
<jkemp> * There is no HTTP-like "uniform interface" yet described
for scripted APIs
<jkemp> * The impact of state on the presence and usage of an API
(for example, how DOM events can affect the results of an API call).
<jkemp> * URIs to resources exposed via scripted APIs (especially in
the case that a URI does not exist for such a resource)
jk: these came from meeting w/Ashok
[31]http://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0
020.html
[31]
http://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0020.html
privacy & security in APIs?
scribe: discussion of geopriv, policy languages, etc...
... whether services that suck your conact list...
am: who is going to enforce this?
dc: if they share the info and get caught they would be busted
am: whoever has access is somehow identified
lm: belief is that it is one bit "public or not"
jk: EU laws, indicate the user agreed to some action
... discussion of 'evil' bit ...
... we tried to use P3P, didn't gain any adoption or consensus
tbl: are they all armchair programmers?
jk: design patterns for extensibility good tag topic, not restricted
to APIs ..
... there are some minor issues here, then there are some other
issues that have broader context....
... other issues that are broader
nm: two statements: (1) there are a bunch of people doing APIs in
javascript, mostly don't need the tag's help
... (2) the tag is here to areas where things are not coming out as
well as it should, and if the TAG gets involved
... I don't hear people popping up and saying "that's not an API"
jk: many people are proposing a way of doing versioning
nm: there are many people who are doing it already
tbl: versioning is icing on the cake, the main problem is that there
is no modules
... if you're using google maps and yahoo maps the two aren't
compatible
dc: panel discussion, as it was breaking up.... can we have the same
thing for loading modules?
nm: if we made a blog posting, that this remains a problem, this
really is troubling?
lm: ECMA & W3C at TPAC question?
is there a meeting planned?
sorry, TC39 and HTML
if we're discussing modularity and APIs
ht: this is one of the 5 unknown problems in Computer Science
tbl: various pieces of software have to do the loading
danc: who makes up package names? debian developer community is
'always on'
jar: replacing short names with URIs
ht: , app.get(banana) changes from week to week
dc: debian community is mutually trusting
tbl: they should be using URIs, for distributed extensibility
jar: necessary level of indirection because of the architecture
tbl: search path, can search things in sequence
<ht> s/Computer Science/practical Computer Science/
<ht> s/unknown/unsolved/
lm: concern about apis using enumerations and characterizing which
apis are supported by which category the device or service is vs.
characteristics or features...
tbl: what about a thing which is a 'calendar' but there are 17
calendars and choose between whether it's a calendar and or a phone
nm: mixins
jar: we have a language for describing things, it's OWL
... this technology covers a large space of the problem
dc: compare this to the user agent header
lm: User Agent is an example of where the web community didn't get
it right
dc: user agent field allows you to know about 'bugs'
nm: gets device characterization
dc: what gets widely deployed are databases that match user agent
fields to database
nm: please give me a short thing
dc: user agent field for iPhone is long
<noahm> Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en)
AppleWebKit/420+ (KHTML, like Gecko)
<noahm> Version/3.0 Mobile/1A543a Safari/419.3
dc: lists all the features because user agent
jar: is this part of a sql query?
action larry to work with JK and AM to update Web APplication
architecture outline based on discussions at TAG meetings
<trackbot> Created ACTION-306 - Work with JK and AM to update Web
APplication architecture outline based on discussions at TAG
meetings [on Larry Masinter - due 2009-09-30].
<noahm> CLOSE ACTION-300
<trackbot> ACTION-300 Prepare draft on device APIs closed
wrap up for the day (agenda review)
action danc to raise issue of work items moving between W3C working
groups and also with IETF
<trackbot> Created ACTION-307 - Raise issue of work items moving
between W3C working groups and also with IETF [on Dan Connolly - due
2009-09-30].
<noahm> Closing action 273
<noahm> ACTION-295 Due 25 Sep
<trackbot> ACTION-295 Monitor geolocation response to IETF GEOPRIV
comments on last call and report to the TAG due date now 25 Sep
<noahm> ACTION-301 Due 24 sep
<trackbot> ACTION-301 Review websocket protocol/api motivation and
brief TAG at Sep ftf due date now 24 sep
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [32]scribe.perl version 1.134
([33]CVS log)
$Date: 2009/10/12 17:21:32 $
[32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[33] http://dev.w3.org/cvsweb/2002/scribe/
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG f2f, day 2
24 Sep 2009
[2]Agenda
[2] http://www.w3.org/2001/tag/2009/09/23-agenda.html
See also: [3]IRC log
[3] http://www.w3.org/2009/09/24-tagmem-irc
Attendees
Present
Tim Berners-Lee, Dan Connolly, John Kemp, (in part), Ashok
Malhotra, Larry Masinter, Noah Mendelsohn, Jonathan Rees,
Henry S. Thompson, ( Lisa Dusseault and Mark Nottingham by
invitation, in part, by telephone)
Regrets
T. V. Raman
Chair
Noah Mendelsohn
Scribe
Henry S. Thompson (morning), Dan Connolly (afternoon)
Contents
* [4]Topics
1. [5]Metadata
2. [6]Content-type sniffing
3. [7]Web Application Architecture
4. [8]Naming Schemes
* [9]Summary of Action Items
_________________________________________________________
Metadata:
[10]http://www.w3.org/2001/tag/2009/09/23-agenda.html#metadata
[10] http://www.w3.org/2001/tag/2009/09/23-agenda.html#metadata
[Two updates for agenda: sessions likely on Javascript security and
Distributed extensibility]
AM: Hoping for drafts from Mark N. and Eren to start from. New draft
has arrived from Mark N., "?? well-known URIs" [ref?]. Apparently a
replacement for the site-meta draft, quite short. JAR likes LM's
suggestion that we work on a whitepaper surveying the state of play
wrt metadata
<DanC_lap> (I didn't get the impression that the well-known URIs
draft was a replacement for site-meta)
<noahm> Well, Dan, the title certainly makes it sound different. I
haven't read it yet. Do we have a link?
JAR: I took an action [ACTION-282] to draft a document in this area,
which got closed for lack of action but I'm willing to resurrect
this because I expect to have some time available not just formats
and transport, but also life-cycle
<DanC_lap> action-281?
<trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress
of link header draft, report to TAG, warn us of problems (ISSUE-62)
-- due 2009-08-01 -- OPEN
<trackbot> [11]http://www.w3.org/2001/tag/group/track/actions/281
[11] http://www.w3.org/2001/tag/group/track/actions/281
<noahm> ACTION-281 Due 30 Oct
<trackbot> ACTION-281 Keep an eye on progress of link header draft,
report to TAG, warn us of problems (ISSUE-62) due date now 30 Oct
<noahm> action-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2009-08-31 -- CLOSED
<trackbot> [12]http://www.w3.org/2001/tag/group/track/actions/282
[12] http://www.w3.org/2001/tag/group/track/actions/282
<noahm> Action 282 was reopened by editing the record, now has note
stating: Reopened at Sept 2009 F2F because Jonathan says he is doing
a draft after all. Expected to cover both access and formats (and
maybe more).
<noahm> The action numbered 282 is now due Oct 13
JR: Next step will be a draft
LM: I'll be happy to contribute effort
<DanC_lap> action-282?
<trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
metadata architecture. -- due 2009-10-13 -- OPEN
<trackbot> [13]http://www.w3.org/2001/tag/group/track/actions/282
[13] http://www.w3.org/2001/tag/group/track/actions/282
Content-type sniffing:
[14]http://www.w3.org/2001/tag/2009/09/23-agenda.html#sniffing
[14] http://www.w3.org/2001/tag/2009/09/23-agenda.html#sniffing
<noahm> Preparing for call with Mark Nottingham and Lisa Dusseault,
which will be in about 30 mins
DC: My starting point is the example of serving XML as text/plain,
because you want to show the angle brackets but if you have various
magic strings near the beginning, browsers will treat it as HTML
anyway. Ian Hickson fought this for 10 years, then gave up and wrote
a description of it (sniffing) into the HTML 5 spec. This was
queried as it wasn't HTML, but rather HTTP. So Adam Barth took the
relevant bit out and wrote it up as an Internet Draft. Not clear
where this draft is heading. Both groups (HTML WG and HTTP bis WG)
have closed their issues on this
NM: What are Lisa and Mark's roles?
DC: Mark is chair of HTTP bis WG, Lisa is relevant IETF Area
Director. Should we leave the unsatisfactory status quo in place, or
try to expose the unsatisfactory nature of the resolution?
LM: This is a kind of error-recovery issue. Browsers are trying to
accommodate users who have tried to publish HTML, but are getting it
served as text/plain, or who are publishing images with the wrong
mime type, typically through no fault of their own
JR: But it's an odd kind of error -- it's undetectable. I've been
burned by precisely DC's example
NM: Example here:
[15]http://www.hoahdemo.com/rte/Metadata/broken_text.xml
[15] http://www.hoahdemo.com/rte/Metadata/broken_text.xml
<noahm> (I may or may not leave that content up there for the long
term...it's a page I put together mostly for my own use, but it's
fine for everyone to try it.)
LM: Hixie is just documenting a compromise position wrt what the
browsers are doing already
<DanC_lap> (Fielding gives a colorful history of the sniffing issue.
I wonder whether to bring it up orally.
[16]http://lists.w3.org/Archives/Public/public-html/2008Jul/0038.htm
l )
[16]
http://lists.w3.org/Archives/Public/public-html/2008Jul/0038.html
HT: My understanding is a bit different from what Dan said. I
started out believing we had a problem. I said in my notes
"shouldn't the fact that Adam Barth's draft is incompatible with RFC
2616" at least be acknowledged in the HTML spec. But, if I "follow
my nose" from HTML issue 5 I get to this message
<ht>
[17]http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0473
.html
[17]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0473.html
<DanC_lap> (I don't think 5 is the right number)
<DanC_lap> relevant HTML WG issue is
[18]http://www.w3.org/html/wg/tracker/issues/28
[18] http://www.w3.org/html/wg/tracker/issues/28
HT: In that, Mark Nottingham says that sniffing does not conflict
with RFC 2616. That issue is closed, but it's not quite clear from
Tracker what logic was used to close it.
DC: We discussed this before, and you agreed.
<ht> [19]http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155
[19] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155
HT: For HTTPBis, it's issue 155, which appears to say that "provided
user controls are in place, sniffing will be allowed."
<DanC_lap> "HST: OK, thanks for clarifying, I understand better now"
-- [20]http://www.w3.org/2001/tag/2009/09/10-tagmem-minutes.html
[20] http://www.w3.org/2001/tag/2009/09/10-tagmem-minutes.html
HT: Seems to contradict Dan's saying that a user surveying pertinent
specs won't discover the problem. I think if HTTPbis goes this way,
we'll have to revisit the authoritative metadata finding.
DC: Would like to see what Henry is referring to.
HT: From HTTP bis issue 155:
HT: The language should be updated to reflect this reality,
without unduly encouraging the use of sniffing except where
necessary. Ideally, it will be done in such a way that:
* Does not require sniffing for all uses of HTTP (i.e., a
particular implementation and/or user can "opt in" to the use of a
sniffing algorithm), since this is most commonly a problem for the
browser case, and
* Specifically allows a user and/or content provider to opt out of
the use of sniffing in a particular interaction, and
* Promotes interoperability (i.e., if two implementations sniff,
they will do so in the same way).
DC: But they didn't do that.
DC: Looking at ticket 155. . .
<noahm> Note proposal 8 weeks ago:
<noahm> Proposal from HTTP WG meeting: remove the sentence:
<noahm> "Note that neither the interpretation of the data type of a
message nor the behaviors caused by it are defined by HTTP; this
potentially includes examination of the content to override any
indicated type ("sniffing")."
NM: It appear that the HTTP bis WG has in fact done that deletion
<masinter>
[21]http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-07
[21] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-07
NM: looking at section 3.2.1 in current draft having difficulties
<DanC_lap>
[22]http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07#sect
ion-3.2.1 perhaps?
[22]
http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07#section-3.2.1
<DanC_lap> "Note that neither the interpretation of the data type of
a message nor the behaviors caused by it are defined by HTTP; this
potentially includes examination of the content to override any
indicated type ("sniffing")."
DC: Not clear if this has been removed
<Zakim> noahm, you wanted to ask about functions vs. specs
NM: Two issues for the TAG:
... 1) How strong do we feel about this?
... 2) What does and should the specs say?
<DanC_lap> (so indeed, it'll be handy to have Mark help us navigate
their issues list and tell us what the status of this issue is.)
NM: We all agree that in the real world this shouldn't be necessary.
But how can the TAG be helpful given the exigencies of the real
world where it is?
DC: I think the Authoritative Metadata should be revised. RF said
"over my dead body" wrt that proposal some years ago
<noahm> [23]http://www.w3.org/2001/tag/doc/mime-respect
[23] http://www.w3.org/2001/tag/doc/mime-respect
HT: No, I remember the exchange: the TAG's position is (was) don't
do that. period.
TBL: The architectural rule is "don't do it"
TBL: That's still the right architectural decision, and when it's
not observed there's damage
<Zakim> timbl, you wanted to wonder about a practical solution being
to involve the user and keep a per-site kludge list like for "bad"
certificates.
TBL: You could address this by browsers have a way to record user
preference to see some 'text/plain' as appl/xml then you could
generalise to "should I always treat text/plain from [this site] as
appl/xml?"
LM: But there's no point in writing a spec. if browser makers won't
attend -- true or false?. I haven't been able to rebut this
TBL: For example, wrt certificates, we argued for years to improve
things, and they finally moved. We could find out what the facts
are, and if we made a proposal which helped the browsers, they might
find it helpful
LM: So, we could say we don't want W3C to publish a spec. which
encourages sniffing
DC: Not without showing a way out of the current local minimum.
Could we build an extension which illustrated TBL's suggestion?
HST: Depends on whether there's a hook in Mozilla for this case?
DC: Or we could ask for a hook -- that's easier than asking for a
change in the UI
[Lisa Dusseault and Mark Nottingham join the meeting via the 'phone]
NM: Thanks for joining us to discuss sniffing. Our starting point is
that architecturally sniffing is bad, but maybe there's a case for
at least documenting the workarounds for the practical difficulties
caused by misleading media types
MN: Our issue 155 is about sniffing
MN: we came to consensus that HTTP should get out of the business of
ruling out sniffing and just say that Content-type: is for users to
indicate what they think, but not say "don't sniff". So don't
encourage it, and certainly not require it, but stop making it
non-conformant to do it. Then there can be a draft such as Adam
Barth's. There was discussion about including something in the HTTP
bis draft itself on how to sniff, but we didn't go there
NM: Stable now? Anyone pushing back?
HT: The last decision we see recorded on your issue 155 seemed to be
to remove the text.
MN: I believe it's stable
HST: But you appear to have removed the spec. which allows it
<DanC_lap> "nothing in the HTTP spec that says you can't". so the
spec is silent on it.
MN: But there's nothing which rules it out -- we pulled that text
because some people thought it went too far towards encouraging
sniffing
LD: We've told Adam Barth that to take his work forward, he would
need to either: 1) Form a WG around this topic to take it forward;
2) Get it encorporated in the HTTP bis draft (although MN has
declined to do this for the time being); 3) Get an Area Director to
sponsor its publication as an Informational [RFC]
NM: Could HTML 5 reference an Informational normatively?
LD: That's a complex question of how W3C and IETF processes
interact. . .
LM: We're still dancing around the question of what the right
behaviour is wrt the fact that deployed software does error recovery
which is heading for being embedded in standards. I'd like to avoid
having this stuff ping-pong between W3C and IETF
TBL: I put myself on the queue to say I would like a name for a
clean HTTP. If there's sniffing in it, call it something other than
HTTP -- HTTP_unclean. We should continue to promote the clean
version
NM: Do you want the difference in-band in the requests?
TBL: No
DC: Wrt ping-pong, when one org's group starts overlapping with the
other's, there has to be interaction at least we got the overlap
area broken out into its own draft but the HTTP bis WG has decided
to be silent about this. So the question has become whether to
reabsorb the AB draft, or sight it as Informational
LD: I don't know about your process, but we have an explicit
mechanism in our process for referencing an Informational
DC: You can do it unless someone complains
LM: It's like referencing a Note -- can you do that normatively?
HST: Yes
DC: Unless someone complains and it's upheld
<noahm> [John Kemp arrives]
MN: We were asked to confirm that HTTP bis doesn't conflict with
sniffing, and we decided to accept that. At the moment we're waiting
to see where AB's draft goes. It's not strictly speaking in our
charter to incorporate it. But we could revisit that if we needed to
-- might require agreement from Lisa. Wrt HTTP_Unclean, we should
come up with a browser profile for HTTP usage, which said "use [this
URI cleanup] and [this sniffing] specs in this way". So it would be
a separate profile, rather than forking the HTTP spec itself
TBL: So documenting a set of willful violations would be a good
thing?
MN: We're coming to the conclusion that it's not a violation
<Zakim> masinter, you wanted to ask whether there have been other
cases where stuff has bounced over the boundary between application
semantics and protocol semantics
MN: Remember WSI -- they built profiles by combining other specs --
HTML 5 should be a spec. for a language, and a story about browser
behaviour should be told elsewhere, in a similar way to the WSI
stuff
LM: HTTP defines the protocol and what it means, and the browser
spec. specifies how it uses the protocol, with some wrapping/post-
and pre- processing. E.g. "HTTP says this is 'text/plain', but in
such-and-such a case, you should ignore that and use ... instead" is
there another example of this?
MN: Content-type and Content-encoding
LM: That's for browsers -- any other applications -- using SIP (?)
for instance?
MN: Not aware of any. . .
LD: There is some precedence for one IETF spec. saying "MUST" which
overrides a "MUST NOT" in another spec.
LM: What about CRLF in mime vs in HTTP -- HTTP overrode that to
match current practice
MN: Yes, header length and header wrapping minutiae -- HTTP is not a
mime protocol but its a mime-like protocol. . . .
HT: Part of the TAG history, is that when we last discussed this
issue, in the context of our "Authoritative Metdata" findin", we
decided not to change it. The finding thus continues to say that
authoritative metadata is binding. We believe that finding author
[editor?] Roy Fielding's view is that changing this would be "over
his dead body". Seems like people are feeling "worn down". I think I
know what Roy would say. But...
MN: Hard to answer
<Zakim> lisa, you wanted to try to sum up current consensus
MN: We did pull that text we talked about, because it was too
explilcit -- "not in our spec.", what they do in their own specs is
on their back
LD: We are doing more reality-based protocol design, less policing.
Maybe this means lots of health warnings. So e.g. Geopriv clients
shouldn't accept 'text/plain'....
MN: The concerns haven't been so much around purity, as around the
viability of this as a long-term solution
<timbl> Go not gently into that good night -- but fight, fight
against the dying of the light. [From Dylan Thomas Do not go gentle
into that good night]
LD: Having a real document setting out how it can be done reasonably
well changed the debate
TBL: But it's harmful, it makes things break -- we can't forget
that. If you intentionally serve some XHTML as text/plain, as an
example, it's just broken if that isn't displayed as such
<noahm> Example that breaks browsers that sniff:
[24]http://www.noahdemo.com/rte/Metadata/broken_text.xml
[24] http://www.noahdemo.com/rte/Metadata/broken_text.xml
TBL: there are also potential security holes. It makes specs more
complicated. It's important to describe the system which works as
the architecture specifies
<noahm> The example is meant to illustrate a bug reporting system,
in which the desire is to show the user buggy XML as text/plain.
TBL: and separate out the accommodations. I'd like a browser to
prompt me before using sniffing to decide how to render, so I can
decide whether I want this done for this site
NM: Positive steps?
TBL: I like the idea of a browser profile -- put all the kludges and
fixups there. But I don't want HTTP to include a sniffing section
NM: So the current HTTP spec. is OK by being silent?
TBL: I'd prefer it to point out the damage the comes from sniffing,
but also reference the AB draft
<HST:> HST thinks "Your foot, your gun, your bullet"
LD: Yes, we are trying to work that way
NM: If the TAG were to undertake to produce a finding or a REC of
the form "Here are guidelines for using internet protocols and
formats such as HTTP and media types and ... in a style which meets
the needs of the browsing community" which would either explain how
or point to e.g. AB's draft on how to do this, and point out the
pros and cons is that what you had in mind TBL, and should the TAG
do it?
<masinter> I like this: MIME types, URIs, HTTP protocol, maybe other
IETF BCPs?
TBL: I think it should happen elsewhere
NM: More to do with LD and MN?
HST: No
NM: MN and LD, anything more?
LD: Better coming from the community
NM: Thank you very much for joining us
<lisa> thanks that was useful to me too
[LD and MN leave the call]
<DanC_lap> some clues on mozilla hooks re media types:
[25]http://brh.numbera.com/blog/2009/02/24/jsonview-view-json-docume
nts-in-firefox/
[25]
http://brh.numbera.com/blog/2009/02/24/jsonview-view-json-documents-in-firefox/
[adjourned for break until 1105]
[resuming]
NM: Agenda discussion -- more on sniffing, or. . .
DC: Sniffing, maybe. How to clean up metadata:. List of legacy
sites. Treat as text/plain option (extension). Opera already has a
list of sites which it patches CSS for or some such. There is a FF
extension which allows JSON to be viewed instead of 'Save As...' so
maybe there could be a generic show as text/plain extension
NM: What about an 'i really mean it' media type header?
HST: Microsoft tried it, didn't they?
TBL: I thought that would have been fine, yes
HST: How does the user indicate to turn that on
TBL: It's turned on by default for new sites
NM: [an untarring example?]
<masinter> example was whether web hosting sites provision servers
by installing (untarring) old blog software that had bug that images
were served as text/plain
JK: Suppose the user maliciously serves javascript as text/plain,
Adam Barth says this is a security hole
DC: This hole requires sniffing for the privilege escalation to
happen
NM: But if you had a switch that said "don't do that", there's not
escalation
DC: [draws and speaks to a timeline]
HST: Does or does not AB's draft mandate leaving explicit text/plain
alone?
[WG reviews the AB draft:
[26]http://tools.ietf.org/html/draft-abarth-mime-sniff-01]
[26] http://tools.ietf.org/html/draft-abarth-mime-sniff-01
JK: OK, explicit text/plain must be left alone
DC: So that's FF behaviour, not IE
<jkemp> (section 3 of AB draft, Web Pages, step 3)
NM: What about images served as text/plain
HST: I think that's caught as binary by the algorithm
[WG goes back to the draft]
TBL: It's not the format that's safe/unsafe, it's what you do with
it. Safari is confused about this. I think this is worth saying
LM: I can see no motivation for ever sniffing postscript or pdf. I
believe that Adobe folks thought this wasn't important to sniff if
it did happen. What's the use case? Or for XML?
TBL: Because stuff is served with no Content-Type?
NM: It's plausible to me that there's PDF being served with no
Content-Type
DC: The goal is to get to the point where if you mislabel your
content you will have to fix it. The new idea is to bake the list of
sites which need to be sniffed into the browsers
LM: If for the only things mislabelled at a site wouldn't give any
clear benefit to users if they were sniffed, then they don't need to
be on the list
HST: How's it going for IE8 wrt conformance opt-out?
DC: I understand this includes a baked-in list of known-need-fixing
sites
TBL: I support this
HST: It's an important precedent for shipping strict and allowing
exceptions to be logged
<Zakim> timbl, you wanted to note that the browser can generate the
lists before it starts using it, if you allow a bit of feedback.
<masinter> i think we should push back on sniffing, that there needs
to be a clear user benefit to someone for sniffing, that it isn't
enough that there's some content that browsers currently sniff, it
actually has to be shown to be important
TBL: The list of legacy sites can grow in a distributed fashion
DC: Lots of cleverness possible here
<masinter> I don't think we should rely on the wisdom of browser
implementors to have actually done the thing that is best for their
users, some browser "error correction" behavior might have been
speculative
NM: What about the "i mean it" flag?
DC: We don't know what the facts are. . .
NM: DC, next step?
DC: Ask Microsoft to do this?. Seems to me this would work
LM: I have come to wanting to push back on the sniffing draft as
being speculative that is, codifying what browsers do, minus
escalation. A lot of these may have been speculative patchup by a
browser implementor but assuming that all of these are actually in
users' interests is dubious. Maybe they were just generalising
unnecessarily. We need to see clear user benefit before we endorse
this, line by line
HST: Isn't sniffing PDF when you have the 'unknown type' case a user
benefit?
LM: No -- I think unknown should always take you to
application/octet-stream, and users have to choose to ignore or
save. Then it's their choice to try it as PDF
NM: Maybe it would be good to find out if the current algorithm is
desirable wrt user benefit, but independently of that, documenting
what current practice is is useful
<masinter> i am opposed to mandating (rather than describing)
behavior that has no clear user advantage, especially where that
behavior is at odds with other specifications
NM: What the TAG should be doing is documenting what is or isn't
good about that, and how it's architecturally good or not
LM: I think the clear priority of the [HTML] WG is to match reality,
and that's not what users need, but what browsers do there's some
correlation, but it's not perfect the pressure to ship is sometimes
primary
<jkemp> if there is the opportunity to do something clever without
negatively impacting security, I think we should leave that
possibility open
NM: Disruption to users is presumably high on the WG's list, we have
to be careful
<masinter> i wasn't arguing this on "architectural purity" grounds,
but on "must have clear user benefit"
HST: Note that contrary to what LM implied, the AB draft goes beyond
just documenting what browsers do, by ruling out priviledge
escalation. . .
DC: LM actually acknowledged that security concerns had led to some
changes
HST: OK, sorry, missed that
TBL: There have been strong statements from the HTML WG that
browsers that don't do sniffing suffer in the marketplace maybe
everybody has converged, so there can't be any hard evidence
<Zakim> masinter, you wanted to say that NM was arguing against a
strawman
TBL: by maybe it can have gone to far
LM: I'm not saying that some sniffing doesn't have user benefit but
that not all of the draft stands up to that test. For example
sniffing postscript is pointless, given that most browsers won't do
anything with the information anyway
<DanC_lap> (timbl re "treat as text/plain", fyi, LeeF just told me
about [27]http://www.spasche.net/openinbrowser/ which seems to
support that.)
[27] http://www.spasche.net/openinbrowser/
NM: But that would compromise vendors ability to say "This version
is backwards compatible with last years", full stop. and not by
cases.
<DanC_lap> ("This extension won't be useful anymore once Bug 57342
and Bug 258012 have been implemented.")
NM: what next?
DC: 1.5 hours on Friday to write a blog post about Hixie's draft?
<noahm> close ACTION-257
<trackbot> ACTION-257 invite Mark Not or Lisa D to revisit progress
in IETF/HTML liaison on content sniffing closed
DC: What about updating authoritative metadata?
HT: Shouldn't that wait on seeing what httpBis says?
HST: I heard TBL say things which suggest we should push back on the
current state of the HTTP bis draft. Because it doesn't say "Don't
do that: sniffing breaks things"
NM: [ proposes update to Self-describing Web, because it assumes
Authoritative Metadata]
DC: +1
<DanC_lap> (what Noah is saying is what I have in mind. We don't
change the architecture, but we do FYI: widely deployed practice
diverges in the following ways...)
<noahm> Right. I would change SDW to say: the chain of
specifications holds only insofar as you act on the authoritative
metadata. That said, if sniffing goes ahead, users should be warned
that they may sometimes be shown information inferred from sniffing,
that such information is not in all cases traceable to the SDW chain
of specs, and thus is to some degree suspect.
DC: I don't think we should change the fundamental conclusion of
Auth. Metadata, but we should clarify that the world hasn't agreed
100%
<jkemp> here's a diff of the changes to HTTPbis for sniffing:
[28]http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155
/155.2.diff
[28]
http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155/155.2.diff
NM: I think we can be confident that some justification for browsers
continuing to sniff will be forthcoming so let's go ahead and
explore updating those two findings
<scribe> ACTION: John to propose updates to Authoritative Metadata
and Self-Describing Web to acknowledge the reality of sniffing, due
2009-10-20 [recorded in
[29]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01]
[29] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01
<trackbot> Created ACTION-308 - Propose updates to Authoritative
Metadata and Self-Describing Web to acknowledge the reality of
sniffing, due 2009-10-20 [on John Kemp - due 2009-10-01].
HST: Are we happy with the state of the HTTP bis draft wrt sniffing?
<DanC_lap> jkemp, are you confident that diff is after the WG
decision that mnot informed us of?
[pause to find authoritative draft of IETF bis part 3]
[30]http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07
[30] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07
NM: Do we believe they are still planning further changes to the
draft at that URI, or is it likely to come out in the current form?
HT: Seems like more changes coming.
NM: OK, then I think it's premature for us to plan a response.
<ht>
[31]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html
[31]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html
<ht> That URI does identify the text after the edit we have been
discussing, to remove the final paragraph of 3.2.1
<DanC_lap> (remind me where the remaining sniffing text is? it
doesn't use the word "sniff")
JK: Another important change, is that an 'if-and-only-if' was
removed from the no-content-type case
trackbot, status?
<scribe> ACTION: Henry S. to bring back proposed TAG pushback on
sniffing and HTTP bis draft
[32]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html, or his recommendation that we leave
it alone [recorded in
[33]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02]
[32]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html
[33] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02
<trackbot> Created ACTION-309 - HST to bring back proposed TAG
pushback on sniffing and HTTP bis draft
[34]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html, or his recommendation that we leave
it alone [on Henry S. Thompson - due 2009-10-01].
[34]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html
[adjourned until 1345 for lunch]
[resuming]
<DanC_lap> js sec, plenary, writing session, what got booted...
<DanC_lap> again, on ECMA foo: Archived-At:
<[35]http://www.w3.org/mid/4ABB67E8.4080408@intertwingly.net>
[35] http://www.w3.org/mid/4ABB67E8.4080408@intertwingly.net%3E
<noahm> ACTION: Noah to check with Sam Ruby on ECMA/W3C activities
at TPAC [recorded in
[36]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03]
[36] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03
<trackbot> Created ACTION-310 - Check with Sam Ruby on ECMA/W3C
activities at TPAC [on Noah Mendelsohn - due 2009-10-01].
<jar> [37]http://www.w3.org/TR/WebIDL/
[37] http://www.w3.org/TR/WebIDL/
<DanC_lap> also note work on a WebIDL checker
[38]http://lists.w3.org/Archives/Public/spec-prod/2009JulSep/0000.ht
ml
[38]
http://lists.w3.org/Archives/Public/spec-prod/2009JulSep/0000.html
<DanC_lap> scribenick: DanC_lap
agenda order is 1, 6, 2
agenda order is 1, 3, 6, 2
Web Application Architecture
action-284?
<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web
Application ( [39]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
) outline with as many sentences as he can -- due 2009-09-15 -- OPEN
[39] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
<trackbot> [40]http://www.w3.org/2001/tag/group/track/actions/284
[40] http://www.w3.org/2001/tag/group/track/actions/284
updated outline:
[41]http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921
[41] http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921
discussion of level of interest, expertise, etc. ...
<masinter> +q to look for areas where this isn't just "good CS",
i.e., things that make this web architecture vs. architecture
discussion of parallels with work on WebArch v1
<Zakim> masinter, you wanted to look for areas where this isn't just
"good CS", i.e., things that make this web architecture vs.
architecture
JAR: I touched on that in "Goals: Network effects, overall user
experience (not just at your site), robustness, enabling automation.
You should read this document if and only if you care about these
objectives."
LMM: the 2 I can think of are: relationship beetween the
static/document web and the semantic web and the application web the
google maps URI for something was a good example. [of ...? scribe
might have missed a bit]
... 2) trust. in AWWW [webarch v1] there's discussion of authority
and ownership, which is a sort of trust model...
HST concerned he's missed some of the scribe log -- RRSAgent wasn't
watching -- we seem to drop into the middle of the web sockets topic
http://jkemp.net/tag/hybi.html -- DanC, do you have local copy?
<masinter> if I'm running web sockets and i'm talking to someone i
know is running web sockets, that's the simplest method, we'll just
talk websockets
LMM: e.g. it might be used to get stock quotes, but not by a RESTful
GET on a stock price resource.
<masinter> but if you're over port 80 and you're in a hotel and it
is noon, port 80 request might get intercepted and the hotel ask you
to log in and pay for another day's internet access
LMM: no links, bookmarks, etc. ... like web services
HT asked for a motivating example in order to get context for [which
question? scribe lost the train of thought]. We go back to slide
1... IM, multiplayer gaming... TBL suggests collaborative
spreadsheets
HT: years ago Richard Tobin and I did [42]this sort of thing in a
RESTful way... with URIs for the interesting things...
[42] http://www.hcrc.ed.ac.uk/~ht/hotknit/index.html
JK: yes, people do these things over HTTP, in a RESTful way, but
they run into issues... proxies buffer multiple events into one
response another: the 2 connection limit from RFC2616 [which LMM
points out has been relaxed in HTTPbis]...
LMM: the reasons for that 2 connection limit are historical; it's
been replaced by "do the right thing"
JK: 3) the UPGRADE header is not passed along by proxies
DC: huh? how did UPGRADE come up in a list of issues re RESTful
access?
<Zakim> DanC_lap, you wanted to ask LMM more about IETF status of
hybi wiki and to note the presentation I saw at the SFO IETF
convinced me you need 2 HTTP connections
HT: Why do Bayeux and BOSH need to use Upgrade: ?
DC: I saw a presentation on several of these. One was from Jabber
XMPP suggested best design is two connections.
NM: To avoid deadlock?
DC: Maybe, or might have been Javascript issues. Anyway, Websockets
is only one connection.. Larry, you said are we aware of hybi, and
we said yet. Then you said something about working group. Is there a
working group?
LM: There was BOF and discussion of proposed charter
DC: on hybi... when is it likely to be an IETF WG?
LMM: at the Nov IETF meeting in Hiroshima... the charter wrangling
issue is whether a "2 browsers" constraint should go in the charter
as to why this shold be a WG... it's to get the middle of the
network.. proxies... cisco... to acknowledge this as legitimate to
address reliability issues
<masinter>
[43]http://www.ietf.org/mail-archive/web/apps-discuss/current/msg009
74.html
[43]
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00974.html
NM: what I wonder if what the TAG should do is... consider this
story...
<jkemp> [44]http://trac.tools.ietf.org/bof/trac/wiki/HyBi a good
resource
[44] http://trac.tools.ietf.org/bof/trac/wiki/HyBi
NM: [something about self description or not. scribe is lost.] media
types... following links... content negotiation to use same URI for
RDF and HTML representations so that's motivation for traditional
RESTful access...
<jkemp> Note:
<jkemp> A sentiment has been expressed that perhaps the HyBi group
should not try to pick a specific "winner" with regards to
selecting a single bidirectional protocol. Instead the group could
examine issues that exist for using the HTTP upgrade mechanism to
upgrade to an arbitrary bidirectional protocol and produce
recommendations for HTTP clients, servers, proxies and gateways
that would allow various protocols to be used, to evolved and to
compete for wide support.
<jkemp> from HyBi wiki
NM: however, sometimes [this other pattern?] is more appropriate.
the trade-offs are...
JAR: I expect this advice is already known by the relevant
communities
<DC:> [it's not at all clear to me that what websockets is for is
written down anyplace mere mortals should be expect to find]
TBL: even in non-RESTful cases, self-description is nice... e.g.
SMTP "explain"
NM: it's not clear to me that the community knows this stuff. I get
questions about how to think about such things. That's the main
value I get out of TAG findings
AM: in the Web Services world, there are at least a couple specs
that tell you how to do this: WS-notification, WS-eventing... those
are significantly more complicated; they have: subscribe, timeout,
unsubscribe... pub/sub
JK: I think this is much lower layer
AM: transport layer?
JK: yes
HT: NM, when you asked about the TAG's feelings on RESTful access...
I'm surprised you didn't mention the use of GET for something that
can do things
TBL:'UPGRADE' is a get-out-of-jail-free card -- it means the
semantics of the request are changed
HST Ah, ok
<timbl> GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample
<jkemp> ^sample is from
[45]http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-43
[45] http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-43
TBL: historically, I thought of UPGRADE for switching to X
windows... but are there other uses of UPGRADE?
JK: HTTPS
<jkemp> (^sample is from)
<jkemp> [46]http://www.ietf.org/rfc/rfc2817.txt
[46] http://www.ietf.org/rfc/rfc2817.txt
<masinter> Presently HttpCore provides support for HTTP CONNECT
method for establishing end-to-end tunnels across HTTP proxies as
specified in the RFC 2817. However, HttpCore currently does not
support 'Upgrade' / 101 (Switching Protocols) handshaking, which
does not seem as widely used by the common HTTP agents and servers
as HTTP CONNECT.
<masinter> [47]http://issues.apache.org/jira/browse/HTTPCORE-158
[47] http://issues.apache.org/jira/browse/HTTPCORE-158
<masinter> ISA Server does not support the Upgrade header. If a
client sends a request containing this header, it is ignored by
ISA Server. Both client and server will use standard protocols.
<masinter>
[48]http://technet.microsoft.com/en-us/library/cc302548.aspx
[48] http://technet.microsoft.com/en-us/library/cc302548.aspx
<ht> [49]http://issues.apache.org/jira/browse/HTTPCLIENT-751
[49] http://issues.apache.org/jira/browse/HTTPCLIENT-751
JK: The hybi activity seems to have started to document best
practices, because of perception that straight HTTP isn't meeting
the need.
<ht> 2008-02-11: "AFAIK, we're not supporting upgrade of a plain
HTTP connection to HTTPS. We only support dedicated https:
connections so far. HttpClient 4.0 should be flexible enough to
add support for protocol upgrades. "
<ht> [50]http://markmail.org/message/5zhsaxe3bnbd7cee
[50] http://markmail.org/message/5zhsaxe3bnbd7cee
JK: Additionally, the W3C Websocket work has been sent to IETF, but
there are others in IETF hybi who believe that websockets isn't the
best way to meet the need.
JAR: If there's this much activity, it sounds like maybe we should
table this for now.
JK: There's good stuff on their wiki.
DC: When the IETF is working on a charter, think to do is not to
wait.
JAR: Sounds like materials are there.
DC: Can't say.
LMM: if we like the idea of best practices work, we could give that
input now
JK: there are other proposals...
DC: I learned today about the message-oriented framing. That was
useful, thanks.. Use cases on first slide and issues was also
helpful, as was learning about status of WG. So, this was what I had
in mind.
<scribe> scribenick: DanC_
NM: when we hear about other mechanisms... has the implementation
train already left the station?
LMM: no... there's quite spirited discussion among representatives
from Opera, XMPP, Linden labs....
NM: but about browsers...
JK: I think there has been little, but it's starting.
NM: Net, net, would people retune e.g. Firefox impl?
DC: Yes.
<masinter>
[51]http://www.ietf.org/mail-archive/web/hybi/current/msg00559.html
[51] http://www.ietf.org/mail-archive/web/hybi/current/msg00559.html
HT: does the hybi wiki cite this among others?
JK: yes
<ht> [52]http://trac.tools.ietf.org/bof/trac/wiki/HyBi
[52] http://trac.tools.ietf.org/bof/trac/wiki/HyBi
<masinter> [53]http://trac.tools.ietf.org/bof/trac/wiki
[53] http://trac.tools.ietf.org/bof/trac/wiki
<masinter> [54]http://www.faqs.org/rfcs/rfc2324.html
[54] http://www.faqs.org/rfcs/rfc2324.html
<masinter> XXXX is based on HTTP. This is because HTTP is
everywhere. It could not be so pervasive without being good.
Therefore, HTTP is good. If you want good coffee, XXXX needs to be
good. To make XXXX good, it is good to base XXXX on HTTP.
[adjourn for break]
[resume from break]
HT: I hope to hear from LMM about the upcoming [Hybi] BOF
LMM: we could consider this a liaison activity... we expect ...
[pronoun overload; which "they"?]
<masinter> I'm intending to be at IETF meeting and hope to attend
HyBi BOF, but I don't have a commitment to do so, although I'm
interested in the topic personally.
TBL: seems to me people are doing roughly the right thing; I'd be
more motivated to act if it looked like they were doing something
wrong
LMM: it's encouraging that W3C working groups are taking protocol
work to IETF
action-301?
<trackbot> ACTION-301 -- John Kemp to review websocket protocol/api
motivation and brief TAG at Sep ftf -- due 2009-09-24 -- OPEN
<trackbot> [55]http://www.w3.org/2001/tag/group/track/actions/301
[55] http://www.w3.org/2001/tag/group/track/actions/301
close action-301
<trackbot> ACTION-301 Review websocket protocol/api motivation and
brief TAG at Sep ftf closed
DanC: how about a similar session on web storage apis? Maybe I'll
twist arms in a break...
Naming Schemes
<ht> [56]http://www.ltg.ed.ac.uk/~ht/tag_persist/
[56] http://www.ltg.ed.ac.uk/~ht/tag_persist/
action-33?
<trackbot> ACTION-33 -- Henry S. Thompson to revise naming
challenges story in response to Dec 2008 F2F discussion -- due
2009-09-18 -- OPEN
<trackbot> [57]http://www.w3.org/2001/tag/group/track/actions/33
[57] http://www.w3.org/2001/tag/group/track/actions/33
HST presents "Forever is a long time: Real persistence for the Web"
HT: with that, on to JAR's suggestion...
JAR: so take any competent repository administrator or librarian...
they're dealing with all sorts of strings, whether they start with
http: or doi: or otherwise... and on behalf of their users, they
keep track of what these things mean they're going to build or buy
or find a resolver... one choice of providers is ICANN/HTTP/DNS ...
this pattern will hold regardless of which URI scheme they are using
<masinter> need to be careful to talk about the service provider for
name resolution and the guarantee for being the authoritative
service for resolving the name
JAR: suppose the repository manager believes me when I say "you can
use HTTP URIs"... they'll be in the same situation as with urn: or
other syntactic forms, they'll be in the same position of
build/buy/find a resolver... could be a database, proxy, alternate
DNS, etc.
<masinter> I think i really understand this now and i'm frustrated
at not being able to explain it
<masinter> [58]http://larry.masinter.net/duri.html
[58] http://larry.masinter.net/duri.html
<masinter> is one proposed solution
JAR: so if they find some other resolver, they're doing something
that's not sanctioned by Web architecture; not using ICANN/DNS/http
[fixing a bug in ICANN/DNS/http doesn't seem like something "not
sanctioned by Web architecture"]
<masinter> the obtainer of a name gets a "name", but implicitly they
get some kind of service guarantee from a name service provider,
that for the period they have purchased, the name service provider
will tell other people that the name they are using means what the
original name obtainer meant
<masinter> the discussion Henry and JAR tell confuses who gets the
name, who makes the service guarantee, and who is looking up the
name and obtains the name resolution
<Zakim> DanC_lap, you wanted to offer that w3.org falling into the
hands of bad guys is analagous to a linnean animal name morphing
into a trademark for some megacorp
<masinter> using the "wayback" machine leaves open the question of
how far back you go
<masinter> AWWW looks at "meaning" from the wrong end of the
telescope. Meaning can't change based on operational behavior
DC: Not clear why the hypothesised situation would break WebArch
<masinter> if you get a linnean name, you get something from an
organization that offers a long-term name resolution service
<noahm> ... Over time browsers would migrate to new URIs for W3
namespaces
LM: another attempt to explain what I've tried many times... when
you get a name, you think you're getting something. But what you're
really doing is entering into an agreement with a provider who
offers the service of resolving a name
<masinter> [59]http://larry.masinter.net/duri.html
[59] http://larry.masinter.net/duri.html
LMM: [... trust me as an authority]. the urn: scheme delegates that
to [one place] and http: delegates via ICANN/DNS/etc. one idea I've
put some work into is to add a timestamp to a URI... duri means what
that URI meant in the given date the current practice in academic
citations for web pages is to note the date of access
<DanC> (the authority for the Linnaean names is the peer-reviewed
academic community)
<DanC> (which was once one of the few people would could get things
published.)
<jkemp> authority is not noted in the name itself
HT: well, let's please get back to evaluating the AWWW story about
naming and authority
NM: perhaps we should push harder on having some DNS names where
persistence is more guaranteed. e.g. a new root
<masinter> good papers in
[60]http://www.isr.uci.edu/events/twist/twist99/
[60] http://www.isr.uci.edu/events/twist/twist99/
HT: the "more persistent DNS names" idea is good, but making the
domain name/owner binding stronger doesn't amount to a guarantee
that it's perfectly strong
<Zakim> timbl1, you wanted to say one can always make a different
resolver for http uris so long as it doesn't misrepresent -- so long
as it doesn't give wrong data, where right data is
NM: [missed some subtlety about the stronger DNS idea]
<masinter> AWWW is wrong because [61]http://www.w3.org/anything
means "open HTTP connection to www.w3.org and ask it about
"/anything". If you want something else you need "tdb", it's not
optional
[61] http://www.w3.org/anything
<masinter> and it doesn't matter how much you wish anything else
<noahm> I was noodling on the possibility that the guarantee would
be such that W3C or anyone else "owning" a DNS name would have
complete control over lines of succession for it.
TBL: JAR, there are lots of times when people know what an http URI
name means without doing an http lookup; that's fine as long as it's
not inconsistent with what you'd get if you did a lookup
<Zakim> timbl2, you wanted to suggest that extreme scenarious make
bad design. Extreme situations occur with other things -- librraies
with species in can get hacked, and specifically
<masinter> the leap of faith needs to be explicit
JAR: I'm talking about people using resolvers that are inconsistent
with what you'd get with a lookup; e.g. OpenDNS resolves DNS names
that normal DNS doesn't
TBL: starting with a screw case doesn't make for a good argument.
The case of W3C losing w3.org is uninteresting.
TBL: The Commerce Department will take domain names by eminent
domain
TBL: HT started by saying the Linnaean name system works great, but
of course somebody could replace all the books in the library to
screw it up.
<Zakim> timbl3, you wanted to say that in fact in a less wildy
extreme scenario, in fact there is n serious value in pursuing more
persistent domain names which the TAG could follow up
<masinter> 'meaning' is a verb, not a noun. a URI producer 'means'
something and a URI consumer attempts to discover what the URI
producer meant. To define 'meaning' as a noun in AWWW confuses these
things. We're asking producers to have faith that http: URIs to mean
what they want to mean, in order that future consumers can readily
discover their meaning.
<DanC> (HT, recall that I pointed out that the URI would slowly
degrade if the divergence between the software and the server at
w3.org disagreed.)
<noahm> (DanC, I'm not so sure -- why? Everything would continue to
work if both browsers and users continued to use it as the NS URI)
<DanC> (because people would not want to be associated with what the
bad guys publish there)
<jar> timbl: New TLD for use e.g. for persistent http:
<noahm> ACTION Noah to schedule discussion of a persistent domain
name policy promotion
<trackbot> Created ACTION-311 - Schedule discussion of a persistent
domain name policy promotion [on Noah Mendelsohn - due 2009-10-01].
<DanC> ("permanent names" is a category error. as LMM points out,
the request is for "permanent services" which is clearly absurd.)
<Zakim> timbl4, you wanted to point out that this is a question of
trust, and trust has a lot of Not Invented Here to it, and many
people will trust something when and only when they have been
seriously
TBL: the actual case in the lifesci community is about trust...
somehow they trust the LSI committe but not ICANN...
<masinter> [62]http://www.isr.uci.edu/events/twist/twist99/
"problems URIs don't solve"
[62] http://www.isr.uci.edu/events/twist/twist99/
TBL: maybe if they'd been on the ICANN committee they'd trust them
more... or if they'd been involved in HTTP [ESPEAKINGTOOFAST. bzzt.]
LMM: I think AWWW/webarch is wrong because it makes an implicit leap
of faith which needs to be explicit...
<timbl> You can by the way bind the persistence not to an
organization but to content (or meaning if you can define that)
LMM: the step of opening up a connection is implicit... and this
leads to contradictory conclusions
<DanC> (it spells out that stuff a few sections lower)
<jar> there are no guarantees
LMM: if I write a URI in a book, and [something changes] it doesn't
change the meaning of the book. Permanent names don't solve the
problem that they're hoped to solve... financial failures etc. ...
you come to the conclusion... that alternatives are no better than
http
LMM: and in cases like doi and [missed], they're in a commercial
position that we're in no position to argue down
<DanC> (lmm, sorry, I'm afraid I mangled what you said)
<Zakim> jkemp, you wanted to note that Linnaean names don't contain
an authority
JK: Linnaean names have the feature that resolution isn't part of
the name... I can use google...
<jkemp> neither resolution nor (any statement about) authority are
included in Linnaean names
<jar> actually careful biologists will specify the last name of the
author of the authoritative publication...
<masinter> implicitly 'search' becomes the naming system; it's a
problem with folksonomies
<DanC> huh? resolution is involved any time anybody utters a
Linnaean names and hopes somebody to understand
<Zakim> DanC_lap, you wanted to note persistence guarantees mostly
come from either $$/lawers or rich social networks/communities
DC: The way you get persistence is either by protecting it with $$$
or with a large distributed community. IETF is a good example.
Persistent names is a category error, not persistence names, but
persistence services and persistent services are absurd. Endowed
publication is a great idea
TBL: UK gives special status to e.g. the National Trust -- you can't
get their land off them w/o an act of Parliament
HT: yes, Tim, you're right, hard cases make bad law... but certain
constiuencies are obligated to consider the hard cases... these
scholarly edition communities and lifescience identifiers
communities can't avoid it this (2.2.2.1. URI ownership) is all
webarch says about how URIs get their meaning
DanC: no, there's another section on how to resolve URIs
HT: but that says nothing about meaning
<jar> I think how to resolve is not the issue
DanC: see the intro, on the relationship between representations,
URIs, and resources
<jar> (discussion of authority. is there a bug in awww.
disagreement.)
LMM: I disagree that the owner determines the meaning of the URI...
<noahm> LMM: A URI does not lose its meaning because a service
provider fails to deliver on their contractual obligation
<noahm> (HST, e.g. with respect to resolving the domain name part)
JK: You can type the URI into google
DC: Consider the way phone numbers work -- if you stop paying for
your phone, its number will eventually get recycled to call someone
else
<Zakim> jar, you wanted to talk about GBIF WG solution
LMM: It should say that if the ISP misbehaves the meaning of a URI
doens't change. Tim: When we define a protocol, we say that if
everyone obeys these rules, these are the good properties which
result. We don't address normally what happens if you don't obey the
rules.
<Zakim> masinter, you wanted to give some references to twist99
talks and to disagree that the owner of the domain is the
"authority" to determine what the URI "means"
jar: the GBIF task force on identifiers decided that http URIs can
be considered persistent, with alternative resolution option as an
insurance policy against domain name loss. is this approach
consistent with AWWW and the RFCs?
<DanC_lap> [... and that little clause, even if it never happens,
allows these communities to buy in.]
<Zakim> DanC_lap, you wanted to note that IMGT allele names are
being revised this year; things change; these communities deal
<jar> (noting that the GBIF folks tried out urns, and couldn't make
them work... not necessarily through any fault of their own)
DC: You have to get people to use names to get them to mean
anything. Speaking of hard cases the IMGT community are deciding to
change all their names
JAR: They are ill-advised
<DanC_lap> ("the way"? it's an important way... a distinguished
way... but not "the way")
<jar> noahm: usually you poke on something's URI to find out what it
is, but this doesn't always work. you have to reverse engineer
sometimes
NM: If I have a URI which identifies a webcam view of my back door.
If someone else looks at it five nights running, they will
legitimately conclude that my URI identifies a blank page
<jar> (LRDD would be the way you communicate what it's supposed to
mean)
NM: The only definitive way to find what a URI means is to go to the
owner and ask them
LM: No, that's just wrong -- AWWW is broken insofar as it says that
NM: [gives an example, scribe missed]
LM: Scenario 1: I give you a URI. Scenario 2: I give you a URI, but
I tell you at the same time that the URI identifies a piece of
paper, which I hand you. In scenario 2, the URI is useless
JAR: W3C specs are full of this -- they say "This URI means...."
without any necessary correlation with what you get with GET
TBL: Do you mean, e.g., OWL spec says this that and the other are
properties what's wrong with that?
LM: [put a document in a drawer -- scribe didn't catch]
DC: Can I assign meaning to numerals?
LM: You can't -- you can only tell me what you mean by them
JK: We've established community consensus that 23 comes after 22
DC: I give up
HT: I'd like to pick that up sometime
LMM: yes, I've been looking forward to this conversation
HT: Wrapping up... I'd like to come back to this sometime... I've
heard some endorsement of the claim that webarch is incomplete/wrong
on how URIs get and retain meaning...
NM: any other concluding remarks?
LMM: I think trust/belief are important... this conversation where
Dan was getting frustrated... I think he was saying things that
seemed obvious and I wasn't agreeing because he was leaving out
subjects/objects.
<jar> dan likes the succession clause (see my comments above about
GBIF)
DanC: my take-away is that this succession [sp?] clause is
interesting... the fact that it allows people to get on with it
seems great.
NM: the idea about more-permanent DNS names seems interesting...
also, this idea that you can discover resource meaning by
experiment... that it only sometimes works is interesting
action-33?
<trackbot> ACTION-33 -- Henry S. Thompson to revise naming
challenges story in response to Dec 2008 F2F discussion -- due
2009-09-18 -- OPEN
<trackbot> [63]http://www.w3.org/2001/tag/group/track/actions/33
[63] http://www.w3.org/2001/tag/group/track/actions/33
HT: I don't think this is higher priority than review of HTML, but
I'd like to get back to it
<scribe> ACTION: jar to find a path thru the specs that I think
contradicts Dan's reading of webarch [recorded in
[64]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04]
[64] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04
<trackbot> Created ACTION-312 - Find a path thru the specs that I
think contradicts Dan's reading of webarch [on Jonathan Rees - due
2009-10-01].
<jar> (the topic of how to find out what resource is meant has come
up twice in this conversation, from noah and from ht - the idea that
doing GETs is not adequate to find out what it is. ashhok and jar
chant 'LRDD')
<jar> (and i think this orthogonal to the main conversation)
Adjourned until tomorrow
Summary of Action Items
[NEW] ACTION: Henry S. to bring back proposed TAG pushback on
sniffing and HTTP bis draft
[65]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html, or his recommendation that we leave
it alone [recorded in
[66]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02]
[NEW] ACTION: jar to find a path thru the specs that I think
contradicts Dan's reading of webarch [recorded in
[67]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04]
[NEW] ACTION: John to propose updates to Authoritative Metadata and
Self-Describing Web to acknowledge the reality of sniffing, due
2009-10-20 [recorded in
[68]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01]
[NEW] ACTION: Noah to check with Sam Ruby on ECMA/W3C activities at
TPAC [recorded in
[69]http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03]
_________________________________________________________
[65]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html
,
[66] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02
[67] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04
[68] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01
[69] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03
Minutes formatted by David Booth's [70]scribe.perl version 1.134
([71]CVS log)
$Date: 2009/09/29 10:53:15 $
[70] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[71] http://dev.w3.org/cvsweb/2002/scribe/
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TAG F2F day 3 -- 25 Sep 2009
25 Sep 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/09/25-tagmem-irc
Attendees
Present
jar, masinter, noahm, DanC, noah, TimBL, ht, johnk, raman
Regrets
Chair
Noah Mendelsohn
Scribe
Ashok Malhotra, Jonathan Rees
Contents
* [3]Topics
1. [4]HTML Issues
2. [5]HTML
3. [6]HTML Data Facilities
4. [7]TAG admin (TPAC logistics, future meetings)
5. [8]TAG priorities
6. [9]HTML issue: text/html mime type
7. [10]Geolocation/Geopriv
* [11]Summary of Action Items
_________________________________________________________
<Ashok> scribe: Ashok Malhotra
<Ashok> scribenick: Ashok
Noah: reviews the agenda
... I would like to spend majority of our time on HTML
... skip TAG Priorities
... Let's do admin right after lunch
Jar: Let's ask people what they are gonna do
Noah: Let's use Action Item list
HTML Issues
HTML
Noah: What should be next topic for discussion
Larry: I thought were close to consensus on sniffing
Noah: Let's do it on a telcon
Larry: I think we could come up with a position on it.
HT: I have action to propose pushback or accept status quo
Noah: Who wants to discuss sniffing now?
<DanC_lap> action-309?
<trackbot> ACTION-309 -- Henry S. Thompson to s. to bring back
proposed TAG pushback on sniffing and HTTP bis draft
[12]http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf
-httpbis/latest/p3-payload.html, or his recommendation that we leave
it alone -- due 2009-10-01 -- OPEN
[12]
http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html
<trackbot> [13]http://www.w3.org/2001/tag/group/track/actions/309
[13] http://www.w3.org/2001/tag/group/track/actions/309
HT: My inclination is to ask them for a health warning
Larry: I would like to discuss for 10 mts
Poll 3 to 1 ... not now
Noah: What next item to discuss
DC: Data facilities
HT: I would like to report what I found out wrt item 13
HT to give 3 minute report on item 13
HT: I took the binary attribute case
Tim: Boolean
HT: I explored that whereever there was an error there should be
error recovery case
... I sent mail and was told "No, what you say goes in the DOM"
<DanC_lap> (ht, did you say "it's all in public-html"? I don't see
it in
[14]http://lists.w3.org/Archives/Public/public-html/2009Sep/thread.h
tml )
[14]
http://lists.w3.org/Archives/Public/public-html/2009Sep/thread.html
HT: Reason is -- this is an extensibility point
<DanC_lap> (false advertising. this is discussion. not
clarification)
Larry: Is input disabled or is it not?
<DanC_lap> ah... found it: Where is processing of binary attributes
covered? Henry S. Thompson (Wednesday, 23 September)
[15]http://lists.w3.org/Archives/Public/public-html-comments/2009Sep
/0064.html
[15]
http://lists.w3.org/Archives/Public/public-html-comments/2009Sep/0064.html
HT: It IS disabled
... Binary attributes are true if present, false if not present
Larry: So, disabled = false results in TRUE
HTML Data Facilities
Tim: 2 overlapping concerns --- how should data be handled in HTML,
--- overlap with extensibility of tags
... it's important to put RDF into HTML
... RDFa spec tells you how to do that.
... Hixie said removing namespaces was a goal, and it's hard to use
RDFa without namespaces.
Noah: Shall we separate extensibility concerns?
Tim: I'm happy to discuss microdata and Hixie's special data format
<jar> 'rdfh' ... I'd like to hear more about this
Tim writes on board --- RDF in HTML, RDF, microformats,
Data-Attributes, ---- no NS in HTML, Extension Tags
Tim: These are various positions people have taken
<noahm> We are using the queue
<noahm> I think
jar: Has anyone articulated that you might do RDF in HTML w/o
namespaces?
DC: There is a proposal
<jar> the answer was: Yes, data-... does RDF in HTML, but only an
(albeit useful) subset.
Tim: Some say don't bother with namespaces; others say give me the
namespaces tool
<DanC_lap> TBL: the blobs [in the whiteboard diagram] are positions;
the x's are issues.
Larry: HTML5 now has a data format based on no known experience
DC: No deployment of the data stuff
<DanC_lap> blobs = RDF in HTML, RDFa, Need NS in HTML, microformats,
data-*, No NS in HTML, Extending Tags
jar: You could extract triples from data-attributes
DC: That code has been written
Discussion about whether data- or item-property
Noah opens HTML spec
DC: 5.2 Microdata
<DanC_lap>
[16]http://dev.w3.org/html5/spec/Overview.html#encoding-microdata
5.2 Encoding microdata
[16] http://dev.w3.org/html5/spec/Overview.html#encoding-microdata
<DanC_lap>
[17]http://dev.w3.org/html5/spec/Overview.html#custom-data-attribute
3.2.3.8 Embedding custom non-visible data
[17] http://dev.w3.org/html5/spec/Overview.html#custom-data-attribute
DC: Custom data attributes: 3.2.3.8
Noah: What is difference between data- and the item stuff
... if you do data- you get a Javascript object with that name
DC: What's the motivation?
Noah: Extends that data space for Javascript programmers
HT: It's a way of extending attribute space
... The para after the note is the justification
Noah: How [?] different from item-
... is there a glimmer of a comment here?
JK: There may be another position --- no NS mapping rather than no
NS
Noah: There is third position ... just use short names and handle
collisions
Tim: The item- maps to a URI
JK: Section 5.1.3 in WHATWG spec
... says "As URLs"
Larry: This section is non-normative
Tim: This is a competing proposal to RDFa
... subject is where it is attached to
Looking a frag in 5.1.2
Tim: Item property can be a URI or a reverse domain name thingie
Noah: Both data- and item overlap with RDFa
... could extract RDFa from this
jar: That is not a usecase
<Zakim> johnk, you wanted to note that I believe "no namespace
prefix mapping" is more accurate than "no namespace"
Discussion on whether RDFa can be represented in this form
Tim: Go to 5.1.4 and look at example
... 2 properties of Hedral
JK: Section 5.2.3
... Associating names with Items
HT: In 5.1.1 near the end --- properties don't have to be given as
descendents of the element with item attribute
... They can be associated with a specific item using the itemfor
attribute which takes the ID of the element with the item attribute
DC: There is a well-known pattern for licenses for images. Is that
expressible in this syntax.
<timbl> [18]http://dev.w3.org/html5/spec/microdata.html#overview
[18] http://dev.w3.org/html5/spec/microdata.html#overview
HT: Properties that also have values that are URLs. This is achieved
by using the a element and the href attribute, ....
Tim: 5.5.2 RDF ...
<ht> Looks to me that <img src="....." item /> <div style="display:
hide"><a href="xxxxx" itemprop="[CCREL]"></a></div> will do it
Tim: We could make a comment about the process
<Zakim> ht, you wanted to ask about <script
type="text/rdf+xml">...</script>
HT: Minor aspect of script which says the script item is used to
introduce script or data ... type of data is given by type attr of
script
<Zakim> noahm, you wanted to say, I claimed this stuff was related
to GRDDL more than RDFa and to
HT: does not say what you can do with the data
<jar> ben a: " it makes things much more roundabout to write since
itemprop applies to both (either?) @href and the element content"
HT: The item I put in IRC log will do what jar asks
... I left out the ID and the item4
<ht> <img src="....." item id="photo7" /> ... <div style="display:
hide"><a href="xxxxx" itemprop="[CCREL]" subject="photo7"></a></div>
Tim: Critiques the algorithm
<ht> more recent draft uses 'itemfor' for 'subject'
Tim: There is incredible tension between communities expressed on
the board
... TAG could perform useful function.
... is it functionally equivalent to RDFa, or not?
<DanC_lap> ht, we could try out the example you made...
<DanC_lap> [10:17] <Philip> DanC_lap:
[19]http://philip.html5.org/demos/microdata/demo.html ?
[19] http://philip.html5.org/demos/microdata/demo.html
<DanC_lap> [10:18] <Philip> Also
[20]http://james.html5.org/microdata/
[20] http://james.html5.org/microdata/
Larry: I'm concerned about us not driving to statements
<DanC_lap> [10:17] <Philip> DanC_lap:
[21]http://philip.html5.org/demos/microdata/demo.html ?
[21] http://philip.html5.org/demos/microdata/demo.html
<DanC_lap> [10:18] <Philip> Also
[22]http://james.html5.org/microdata/
[22] http://james.html5.org/microdata/
Larry: I have a process suggestion
... create statements and choose between them
DC: That may be helpful
Larry: 10 minutes to solicit things we may say
<noahm> JAR: One thing we might say [straw man] is: "HTML has to
adopt namespaces and RDFa" (not sure I believe that, but it's one
thing we might want to say)
<jar> or reject
<DanC_lap> LMM: I see no justification for reverse domain name
labels where URIs would solve the problem
<DanC_lap> tbl 2nds
Larry: No justification for introducing reverse domain-based
namespace mechanisms are adequate
<DanC_lap> s/are allowed/are adequate/
<jar> (jar was confused by 'reverse DNS' - I think what's meant is
"reversed domain names" and is not related to reverse DNS lookup)
Tim: RDFa and item- are almost identical functionality
... so they create fragmentation which is always damaging
<johnk> Notes:
[23]http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol
3-Quin01.html on "automatic XML namespaces"
[23]
http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol3-Quin01.html
HT: Introducing a new unimplemented and untried design where there
is an implemented tried design is not helpful
<Zakim> DanC_lap, you wanted to say we might say that RDFa should
have no special status just because it's a REC, since W3C allowed it
to go thru CR without coordination with HTML 5
<jar> is there a requirements statement for item, itemprop etc? is
rdf capture a requirement? where articulated?
Noah: The item- is simpler syntactically ... I'm half-convinced
about this
<johnk> ... and
[24]http://lists.xml.org/archives/xml-dev/200907/msg00157.html
"pragmatic XML namespaces"
[24] http://lists.xml.org/archives/xml-dev/200907/msg00157.html
Noah: not enough justification for duplication
<DanC_lap> (re "would anybody use microdata?" there's a relevant
thread at
[25]http://lists.w3.org/Archives/Public/public-html/2009Jun/thread.h
tml#msg732 )
[25]
http://lists.w3.org/Archives/Public/public-html/2009Jun/thread.html#msg732
Tim: RDF is REALLY simple
... first notation for mapping RDF to XML was really complicated
<johnk> "How to make namespaces in XML easier":
[26]http://ln.hixie.ch/?start=1151612438
[26] http://ln.hixie.ch/?start=1151612438
<noahm> I heard Tim say the opposite; I heard him say RDF as a model
is inherently very simple, but RDFa (and also RDF/XML) is
suprisingly complicated
Tim: there is a lot of parser state to be carried along
<ht> s/RDFa is simple/RDF is simple/
<noahm> For those curious about my "Tim said the opposite" comment,
our scribes used log edits to fix what Tim said. I do not believe
said the opposite of the fixed comment.
<timbl> ... aka /opposite/d
BREAK till 10:50
<timbl> I said that RDF/XML was surprisingly complicated, people
saying that that came from its attempt to look like "colloquial
XML"; that we had a few other attempts at syntaxes, including N3,
and then in *ML again we had RDFa, maybe the fourth, which to me was
surprisingly complicated, involving a surprising amount of state to
be held by the parser duriung its recursive descent, and now we have
RDFb (lets call it) whcih attempts the same thing, and again is
surprisingly
<timbl> complicated when you look at the algorithm. Is there a
fundamental difficulty to this challenge?
JK: I pasted a link about distributed extensibility above
<noahm> Chair notes that we are filling some time talking about
proposals that are floating around for namespace-based extensibility
until Tim gets back.
JK: there are other proposals: Liam Quin and Tim Bray's delta on
Micah Dubinko's proposal
<johnk>
[27]http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol
3-Quin01.html
[27]
http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol3-Quin01.html
<noahm> JK: First proposal is Balisage proposal from Liam Quin
<masinter> references include pointer to
[28]http://ln.hixie.ch/?start=1151612438
[28] http://ln.hixie.ch/?start=1151612438
HT: This says we are going to associate NSs with some elements. Does
away with prefixes
DC: There is some outboard doc that gives the mapping
HT: Processors will bake in a version of the doc they support
Noah: Some will be baked in, others [specified] in an outboard doc
DC: Does this work like static scoping?
... if elements indicate namespaces then it's like static scoping
<johnk> xml-dev collated proposal
[29]http://www.dpawson.co.uk/namespaces/index.html
[29] http://www.dpawson.co.uk/namespaces/index.html
JK: This where the thread that Micah started ended up ... this has
notion of reverse domain syntax
... Micah's email
<johnk>
[30]http://lists.xml.org/archives/xml-dev/200907/msg00157.html
[30] http://lists.xml.org/archives/xml-dev/200907/msg00157.html
HT: This is too disruptive, so it's a non-starter
Noah: Do we continue on Data Facilities? or move to other topics?
<Zakim> DanC_lap, you wanted to say that complexity for the parser
is often anti-correlated with complexity for the author
<Zakim> danc2, you wanted to ask who are the daily minutes-editors
DC: There are 2 kinds of complexity: for authors and for parser
writers
Tim: If it's hard to write the parser it's hard for authors
<noahm> In about 7 minutes, which will be ~ halfway through, I will
stop discussion to see if we are closing in on next steps.
<jar> danc: Syntactic sugar and defaults make authoring easier but
parsing harder
Discussion about syntactic sugar
Tim: 2 pieces --- triples and triple state
<DanC_lap> TBL: both [sorts of complexity] make learning the
language harder
<masinter> and also that 'data' and 'metadata' are really the same
DC: Do users grok or not .... people pick up RDFa and use it. People
don't use microdata
<masinter> and also that i think the charter of the group and the
right answer is that neither RDFa nor data should be part of HTML
spec and are out of scope for group's charter, group was charatered
to produce extensibility
Larry: HTML WG was not chartered to do any of this work .... this
ought to be out of scope
... area should be able to evelove independently from the HTML
language
<timbl> [31]http://www.w3.org/TR/rdfa-syntax/
[31] http://www.w3.org/TR/rdfa-syntax/
Larry: HTML is not usually written by humans; it is generated from
database tools
... complicated tool chains
... one of the proplems with NSs is that NS-based markup does not
cut and paste well
<Zakim> masinter, you wanted to talk about complexity for tools for
generating, ability to mash-up, ability to copy-paste
<masinter> without moving to dom
<Zakim> danc3, you wanted to note complexity discussion currently
DC: There are various threads about complexity of HTML5. Opportunity
to get involved in current discussion
<Zakim> johnk, you wanted to ask Larry if he thinks that's true with
XHTML changes
<DanC_lap> Complexity of HTML5 (was Re: The Complexity Argument)
Maciej Stachowiak (Sunday, 20 September)
[32]http://lists.w3.org/Archives/Public/public-html/2009Sep/0814.htm
l
[32]
http://lists.w3.org/Archives/Public/public-html/2009Sep/0814.html
JK: Asks about charter? Should it still be true given that XHTML is
winding down.
... there are specific needs to do the extensibility
<Zakim> DanC_lap, you wanted to note sympathy with the "add an
extensibility mechanism, not RDFa nor microdata directly" position;
GRDDL was based on the head/@profile extensibility
Larry: W3C should charter a group on Metadate .... how to add
Metadata to HTML
DC: Talks about GRDDL as an example
Tim: Are people using GRDDL?
<johnk> DC: notes that GRDDL extensibility is achieved by use of the
HTML profile attribute
JAR: There are (this is irrelevant) XSLT that parse RDF/XML and
produces triples
DC: Community not supporive of my suggestions on extensibility
Tim: Talk about problem with cut/paste of NS-based markup
<Zakim> timbl, you wanted to say that to have a de-prefixed from for
cut and paste woul dbe reasonable.. this works with attributavalues
abut not alas with element names. You can for
Tim: Are there oher reasons why people do not like Namespaces
Noah: We need an Action
<timbl> More generally, to get more arcs in a motivation graph to
elaborate what is on the whiteboard.
<DanC_lap> timbl, another rationale behind the the "no URI prefix"
position is: what happens when you mutate the DOM?
Larry: The HTML WG has pointed out a flaw in XML and we should puch
back on XML's syntax on Namespaces
... TAG could encourage re-examination of Namespaces
<Zakim> noahm, you wanted to try and focus discussion and to talk
about exploring namespaces
Noah: Some sympathy but efforts like that may fail
... suggests some TAG action
... Should TAG analyze the situation?
Larry: The TAG could endorse ongoing work outside and encourage a
W3C activity to look into revising Namespaces
HT: What is the flaw in XML which HTML has called attention to?
<timbl> DanClap, re "no uri prefix" a reasonable position is that
the prefix is just a shorthand, and the DOM is the data model, so
the DOM should have the full URI. (Like the RDF model does). It is
then a serialization option as o whether you se a prefix shorthand.
Noah: Problems with Namespaces ... cut and paste problems, typing
stuff with namespaces turns out to be harder than typing stuff
without
<Zakim> ht, you wanted to ask LM to expand on "HTML requirements"
for XML namespace design
DC: DOM modifications
JK: Sympathetic to Larry's proposal but we need to do our homework.
We should speak to people at Balisage.
Noah: Tries to clarify proposals
HT: We misunderstood Larry use of the word "endorse".
Noah: We need to do homework first
Tim: Reminded of Cambridge Communique time
Noah: Need specific actions
Larry: We could ask XML Core to do some homework
HT: This would require a charter change
Noah: Worries about skill set. Needs knowledge of use of Namespaces
in different contexts
HT: Flaws in XML are not addressed by any of these proposals
<johnk> HT: I heard two proposals - i) propose changes to XML Core
ii) bring together HTML and XML folks to make a namespace proposal
acceptable to both
HT: Requirements did not have anything to do with HTML
Larry: HTML WG found that current XML infoset serialization is too
difficult for them.
... we should examine what infoset would meet their needs and also
allow distributed extensibility
<masinter> there is precedent for W3C working on alternative
serializations of XML
Larry: This is not a short-term comment to HTML WG. There is some
long-term work that W3C should take up to prevent communities from
forking off
<masinter> this isn't the 'solution', but I am very concerned about
W3C endorsing two separate forks of HTML on the one hand and XML on
the other, and that perhaps this is 'research', but that the TAG
should lead effort toward convergence
<masinter> i don't want the default answer to be "oh well, i guess
they're different, let's just leave them going off in different
directions"
Tim: XML Model, HTML model and RDF model is a triangle. Trying to
harmonize may be a mistake. Should be arms-lenghth relationship
... Narrow the scope to attribute values, not attribute or element
names
Noah: Please type possible actions into IRC log
<johnk> I am suggesting that I talk to those who went to Balisage,
and ask what was discussed regarding the namespace-focused work
there, and report back to TAG
<timbl> In other words like microdata and RDFa, use the *ML DOM as
it is and putthings in the attribute values.
<DanC_lap> maybe invite advocates of a few of the positions tbl put
on the board (see "blobs" above) to a TAG meeting to discuss them.
<timbl> +1 to JohnK anyway
<masinter> i suggest johnk also float the idea of further work
specifically on this, and that we ask also HT to explore the
questions with XMLCore
<masinter> i suggest the tag also put out a position that we would
like to see work in this area
<noahm> Larry offers to take action to draft message that the TAG
will endorse
<masinter> possibility of coming up with a new serialization of
infoset, which would be acceptable to HTML community, please explore
HT: Larry phrased a new serialzation of the Infoset . I can ask
XMLCore. Asking them to chamge XML would be much more contentious
<masinter> "please ask the XMLCore group what in the area of
discovering and meeting HTML's requirements they would be willing to
do, and what prerequisites they would have for doing it"
<masinter> i propose Henry do what I just typed
Noah: Will you take an action to come back to TAG with a proposal
for whether and how TAG should interact with XML Core re. Infoset
serialization
HT: I don't know what HTML's requirements are
Tim: Too vague ....
HT: I will think about that
<johnk> ACTION: John to talk to Balisage participants about XML
namespace work, discuss TAG interest in this area, and summarize
recorded in [33]http://www.w3.org/2009/09/25-tagmem-irc]
[33] http://www.w3.org/2009/09/25-tagmem-irc
<trackbot> Created ACTION-313 - Talk to Balisage participants about
XML namespace work, discuss TAG interest in this area, and summarize
[on John Kemp - due 2009-10-02].
DC: Any volunteers to get the concerned players together?
JK: I can ask the Balisage players
<johnk> DC: That's not who I meant
HT: No, the players for the consitituencies on the board
Suggestions - invite Ben Adida, Manu
Larry: Possibility of meeting at TPAC?
BREAK for LUNCH
Reconvene at 1:15 PM
<jar> scribe: Jonathan Rees
<jar> scribenick: jar
dan does wed cleanup
ht does thu cleanup
jar does fri minutes cleanup
noah will collate / link all minutes
Reconvening.
<ht> TV, dial in to discuss next meeting, please?
<ht> Raman?
<ht> T.V.?
<timbl> People in the room wave to Raman.
noah: admin review. note, membership is turning over a bit
ht: All please think about who should stand for membership
TAG admin (TPAC logistics, future meetings)
noah: Future meetings: TPAC and Dec 8-10
Dec 8-10 will be at MIT again
<DanC_lap> (anybody want to offer, here in IRC, to host a meeting?
at least tentatively?)
After that: An idea: co-locate TAG and IETF, Anaheim, March ?
AC meeting is at MIT Mar 21-23
Mar 21-23 is Sun-Tue. LM proposes TAG just before that
scribe: more discussion of meeting planning ...
Noah: MIT Mar 17-19 ?
ashok: too early to tell
(no one is saying they can't make that)
Passed - subject to possible future modification - but for now let's
plan on MIT Mar 17-19
RESOLUTION: TAG F2F, MIT, Mar 17-19
<scribe> ACTION: noah Check with Amy on room availability and
suggest to Ian that he mention this meeting in TAG election call for
nominations [recorded in
[34]http://www.w3.org/2009/09/25-tagmem-irc]
[34] http://www.w3.org/2009/09/25-tagmem-irc
<trackbot> Created ACTION-314 - Check with Amy on room availability
and suggest to Ian that he mention this meeting in TAG election call
for nominations [on Noah Mendelsohn - due 2009-10-02].
<noahm> Who will be @ TPAC?
<noahm> Henry, Dan, Ashok, Larry
<noahm> TPAC regrets: John and Jonathan and Tim
noahm: We will meet Mon am, Fri am; available to meet with other WGs
at other times
noah: We used to have TAG progress reports, that stopped at some
point, any interest now? (probably not)
... Any WGs we want to reach out to?
... The meeting at plenary in France was really good
<scribe> ACTION: DanC to follow up on best plan for HTML / TPAC
recorded in [35]http://www.w3.org/2009/09/25-tagmem-irc]
[35] http://www.w3.org/2009/09/25-tagmem-irc
<trackbot> Created ACTION-315 - Follow up on best plan for HTML /
TPAC [on Dan Connolly - due 2009-10-02].
<amy> i confirm I've reserved space for 17 March in G449 (Kiva); 18
March in room 346 (Kiva and Star were not available) and on 19 March
in G449 (Kiva)
<ht> Amy ++
DanC: Re ECMA, Sam suggested Friday, but there was a conflict
noah: Meet separately with ECMA folks?
lm: primary discussion around ecma is around process, as much around
technical work. we can make ourselves available of course
action-310
<DanC_> action-310?
<trackbot> ACTION-310 -- Noah Mendelsohn to check with Sam Ruby on
ECMA/W3C activities at TPAC -- due 2009-10-01 -- OPEN
<trackbot> [36]http://www.w3.org/2001/tag/group/track/actions/310
[36] http://www.w3.org/2001/tag/group/track/actions/310
TAG priorities
sort actions by owner
<DanC_> action-116?
<trackbot> ACTION-116 -- Tim Berners-Lee to align the tabulator
internal vocabulary with the vocabulary in the rules
[37]http://esw.w3.org/topic/AwwswDboothsRules, getting changes to
either as needed. -- due 2009-08-01 -- OPEN
[37] http://esw.w3.org/topic/AwwswDboothsRules
<trackbot> [38]http://www.w3.org/2001/tag/group/track/actions/116
[38] http://www.w3.org/2001/tag/group/track/actions/116
<DanC_> action-116 due 1 Dec
<trackbot> ACTION-116 Align the tabulator internal vocabulary with
the vocabulary in the rules
[39]http://esw.w3.org/topic/AwwswDboothsRules, getting changes to
either as needed. due date now 1 Dec
[39] http://esw.w3.org/topic/AwwswDboothsRules
Timbl: It's good to be reminded of it
<DanC_> close action-24
<trackbot> ACTION-24 clarify [40]http://www.w3.org/2003/04/iri ,
perhaps by using N3 closed
[40] http://www.w3.org/2003/04/iri
timbl: (refers to new IRI spec drafts)
<DanC_> action-24: withdrawn in Cambridge. TBL suggests LMM consider
stuff in this area
<trackbot> ACTION-24 clarify [41]http://www.w3.org/2003/04/iri ,
perhaps by using N3 notes added
[41] http://www.w3.org/2003/04/iri
lm: The new drafts should not influence whatever action is implied
by this action item
timbl: Would like to drop it.
<DanC_> close action-24
<trackbot> ACTION-24 clarify [42]http://www.w3.org/2003/04/iri ,
perhaps by using N3 closed
[42] http://www.w3.org/2003/04/iri
Dan's actions:
ACTION-307?
<trackbot> ACTION-307 -- Dan Connolly to raise issue of work items
moving between W3C working groups and also with IETF -- due
2009-09-30 -- OPEN
<trackbot> [43]http://www.w3.org/2001/tag/group/track/actions/307
[43] http://www.w3.org/2001/tag/group/track/actions/307
lm: This is a process issue, I don't think it's finished
... Hypertext coordination group might take this on?
danc: If I don't get this done today I don't want to carry it
action-299?
<trackbot> ACTION-299 -- Dan Connolly to notify the TAG when the
HTML WG gets closer to closing issue-4 html-versioning -- due
2009-09-10 -- OPEN
<trackbot> [44]http://www.w3.org/2001/tag/group/track/actions/299
[44] http://www.w3.org/2001/tag/group/track/actions/299
<DanC_> action-299 due 15 Oct
<trackbot> ACTION-299 Notify the TAG when the HTML WG gets closer to
closing issue-4 html-versioning due date now 15 Oct
action-295
action-295 due is 1 week
<trackbot> ACTION-295 Monitor geolocation response to IETF GEOPRIV
comments on last call and report to the TAG due date now is 1 week
danc: Discussion is out of order
... of the actions that is
... (Generally, not action) HTML validation software dev work that I
might do
(danc was addressing JAR's request to hear from everyone re tag work
they planned for this fall)
action-308?
<trackbot> ACTION-308 -- John Kemp to propose updates to
Authoritative Metadata and Self-Describing Web to acknowledge the
reality of sniffing, due 2009-10-20 -- due 2009-10-01 -- OPEN
<trackbot> [45]http://www.w3.org/2001/tag/group/track/actions/308
[45] http://www.w3.org/2001/tag/group/track/actions/308
action-308 due 20 october
<trackbot> ACTION-308 Propose updates to Authoritative Metadata and
Self-Describing Web to acknowledge the reality of sniffing, due
2009-10-20 due date now 20 october
lm: i don't like this action. you should refuse to do it
danc: Out of order
action-313?
<trackbot> ACTION-313 -- John Kemp to talk to Balisage participants
about XML namespace work, discuss TAG interest in this area, and
summarize -- due 2009-10-02 -- OPEN
<trackbot> [46]http://www.w3.org/2001/tag/group/track/actions/313
[46] http://www.w3.org/2001/tag/group/track/actions/313
action-313 due 20 october
<trackbot> ACTION-313 Talk to Balisage participants about XML
namespace work, discuss TAG interest in this area, and summarize due
date now 20 october
<DanC_> action-313 due 20 Oct
<trackbot> ACTION-313 Talk to Balisage participants about XML
namespace work, discuss TAG interest in this area, and summarize due
date now 20 Oct
action-281?
<trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress
of link header draft, report to TAG, warn us of problems (ISSUE-62)
-- due 2009-10-30 -- OPEN
<trackbot> [47]http://www.w3.org/2001/tag/group/track/actions/281
[47] http://www.w3.org/2001/tag/group/track/actions/281
ashok: ongoing
action-304?
<trackbot> ACTION-304 -- Larry Masinter to draft summary of the
larger issue -- due 2009-09-30 -- OPEN
<trackbot> [48]http://www.w3.org/2001/tag/group/track/actions/304
[48] http://www.w3.org/2001/tag/group/track/actions/304
noah: This is worth pursuing; need to look at minutes to see what
it's about
johnk: This was about the references in the HTML spec. HT had one
action, LM suggested there was a larger issue around references
action-304 due in one week
<trackbot> ACTION-304 Draft summary of the larger issue due date now
in one week
johnk: What the web platform looks like.
lm: I remember - I was going to add it to the versioning document
<noahm> action-304?
<trackbot> ACTION-304 -- Larry Masinter to larger around Web
Platform Definition regarding references in HTML 5 document -- due
2009-09-30 -- OPEN
<trackbot> [49]http://www.w3.org/2001/tag/group/track/actions/304
[49] http://www.w3.org/2001/tag/group/track/actions/304
<masinter> regarding the definition of the 'web platform' with
regard to specs defined in the HTML5 document
action-action-306?
action-306?
<trackbot> ACTION-306 -- Larry Masinter to work with JK and AM to
update Web APplication architecture outline based on discussions at
TAG meetings -- due 2009-09-30 -- OPEN
<trackbot> [50]http://www.w3.org/2001/tag/group/track/actions/306
[50] http://www.w3.org/2001/tag/group/track/actions/306
<masinter> the general idea is that the web platform consists of a
set of interfaces, HTML, DOM, URI, RDF, images, etc., and that an
overall spec defining the platform should then make reference to
versionless versions of specs and alternatives
close action-306
<trackbot> ACTION-306 Work with JK and AM to update Web APplication
architecture outline based on discussions at TAG meetings closed
reopen action-306
<trackbot> ACTION-306 Work with JK and AM to update Web APplication
architecture outline based on discussions at TAG meetings re-opened
ashok: Let's meet at the end of next month
<DanC_> action-306: this is a follow-on action
<trackbot> ACTION-306 Work with JK and AM to update Web APplication
architecture outline based on discussions at TAG meetings notes
added
<DanC_> action-306?
noah: Please annotate the action in tracker?
<trackbot> ACTION-306 -- Larry Masinter to work with JK and AM to
update Web APplication architecture outline based on discussions at
TAG meetings -- due 2009-09-30 -- OPEN
<trackbot> [51]http://www.w3.org/2001/tag/group/track/actions/306
[51] http://www.w3.org/2001/tag/group/track/actions/306
action-311?
<trackbot> ACTION-311 -- Noah Mendelsohn to schedule discussion of a
persistent domain name policy promotion -- due 2009-10-01 -- OPEN
<trackbot> [52]http://www.w3.org/2001/tag/group/track/actions/311
[52] http://www.w3.org/2001/tag/group/track/actions/311
ht: This was to follow up on Tim's plea to do something about
persistence of w3.org or persistent domains generally
[well that's not exactly what henry said.]
<DanC_> action-311: tbl notes
[53]http://www.w3.org/DesignIssues/PersistentDomains
[53] http://www.w3.org/DesignIssues/PersistentDomains
<trackbot> ACTION-311 Schedule discussion of a persistent domain
name policy promotion notes added
action-285 due in 2 weeks
<trackbot> ACTION-285 Make sure TPAC logistics are straight due date
now in 2 weeks
<DanC_> action-285?
<trackbot> ACTION-285 -- Noah Mendelsohn to make sure TPAC logistics
are straight -- due 2009-09-25 -- OPEN
<trackbot> [54]http://www.w3.org/2001/tag/group/track/actions/285
[54] http://www.w3.org/2001/tag/group/track/actions/285
action-292?
<trackbot> ACTION-292 -- Noah Mendelsohn to alert group to review
HTML Authoring Drafts [trivial] [self-assigned] -- due 2009-10-13 --
OPEN
<trackbot> [55]http://www.w3.org/2001/tag/group/track/actions/292
[55] http://www.w3.org/2001/tag/group/track/actions/292
noah will schedule discussion on this
action-284?
<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web
Application ( [56]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
) outline with as many sentences as he can -- due 2009-09-15 -- OPEN
[56] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
<trackbot> [57]http://www.w3.org/2001/tag/group/track/actions/284
[57] http://www.w3.org/2001/tag/group/track/actions/284
<DanC_> ACTION-292: LMM notes Mike Smith's HTML spec is relevant
<trackbot> ACTION-292 Alert group to review HTML Authoring Drafts
[trivial] [self-assigned] notes added
close action-284
<trackbot> ACTION-284 Flesh out the Web Application (
[58]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ) outline
with as many sentences as he can closed
[58] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
awwsw is talking about tag dec f2f as a 'delivery date'
action-312 due 1 december
<trackbot> ACTION-312 Find a path thru the specs that I think
contradicts Dan's reading of webarch due date now 1 december
action-312 due in one week
<trackbot> ACTION-312 Find a path thru the specs that I think
contradicts Dan's reading of webarch due date now in one week
action-201 due on 1 december
<trackbot> ACTION-201 Report on status of AWWSW discussions due date
now on 1 december
action-278 due 15 october
<trackbot> ACTION-278 Draft changes to 2.7 of Metadata in URIs to
cover the "Google Calendar" case due date now 15 october
<DanC_> action-282: jar says this is his project for the fall
<trackbot> ACTION-282 Draft a finding on metadata architecture.
notes added
action-33 due 15 october
<trackbot> ACTION-33 revise naming challenges story in response to
Dec 2008 F2F discussion due date now 15 october
<DanC_> (larry, is there a draft of HTTPbis which has advice on
conneg?)
action-232 due in 4 days
<trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft
of HTTPbis which has advice on conneg due date now in 4 days
<masinter> (DanC, my proposed revision hasn't been incorporated yet)
<DanC_> (tx)
action-232 due on 29 september
<trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft
of HTTPbis which has advice on conneg due date now on 29 september
<masinter> danc
[59]http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0792
.html
[59]
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0792.html
action-163 due 31 october
<trackbot> ACTION-163 Coordinate with Ted to build a sample catalog
due date now 31 october
discussion of action-295
noah: Back to the spreadsheet
[60]http://www.w3.org/2001/tag/2009/09/HTMLIssues.xls
[60] http://www.w3.org/2001/tag/2009/09/HTMLIssues.xls
HTML issue: text/html mime type
<masinter> [61]http://tools.ietf.org/html/rfc2854
[61] http://tools.ietf.org/html/rfc2854
lm: RFC2854 is current definition of text/html. written by lm and
danc
... history ... mime types are allocated by IETF. Registration at
top level requires IETF consensus
... you designate a change controller. for text/html, it's W3C
... I assume that means rec, not a WG last call
<DanC_> [62]http://www.ietf.org/rfc/rfc2854.txt The 'text/html'
Media Type
[62] http://www.ietf.org/rfc/rfc2854.txt
lm: The proposal in HTML5 is to replace registration with something
*not* including any history [background]
... anything you 'should' need to know is contained in the rec,
anything else is a bug
noah: What is typical?
danc: There be dragons
lm: It's typical to include history, making updates less of an issue
... One reason given is to revoke the permission to serve
XML-expressed HTML as text/html
noah: Breaks our agendas and minutes?
danc: Probably not, since they match the syntax and semantics of
HTML5
timbl: The notion that there is an XML language that is an HTML
language is important as a matter of principle
... and that you can serve it as text/html
noah: The new spec correctly interprets [XHTML] content
lm: (no...)
noah: You shouldn't take stuff that's widely deployed and break it
danc: Depends on what you consider 'widely deployed'
lm: Purpose of mime type is give an out of band description of what
the sender intended
... It's not normative, it indicates intent
noah: Self-describing web has a story about answering the question
"did so and so serve a document x that can be interpreted according
to such and such interpretation rules" (jar's paraphrase)
lm: E.g. the profile attribute of head isn't in html5.
Receiver has no clue what the sender might have meant by a profile
attribute.
If the mime type registration doesn't give history, receiver doesn't
have a chance.
danc: There is some former-features explanation
timbl: Safest thing to do might be to make a historical RFC...
(someone:) how would that help follow your nose?
ht: At the moment we have hearsay, can we have some references?
Nothing in the July draft that looks like a mime type
registration... up to date reference?
<DanC_>
[63]http://dev.w3.org/html5/spec/Overview.html#iana-considerations
[63] http://dev.w3.org/html5/spec/Overview.html#iana-considerations
<DanC_> 12.1 text/html
<ht> What's the issue number for discussion of this?
[scribe notes that this is not a dated file. may change]
timbl: Bold and emphasized text - that must be a funny story
ht: You're now no longer allowed to serve some xml with this label.
The question is whether reinterpreting as html changes the document
in any visible way
<masinter> there were 5 different specifications and languages and
mulitiple implementations that the previous RFC made reference to...
these languages were more or less coherent and correlated. Writing
the history of each element piece by piece is not the same
danc: table with tr right underneath it - tbody gets implicitly
added by html at parse time - so different dom
<DanC_> (hmm... looking for a historical explanation of
head/@profile, I don't see that, but I see "must not be used by
authors" with what to do instead; it says "unnecessary; omit it
altogether, and register the names.")
lm: there used to be many html versions... the fact that someone
might meant one of those is lost when you chop it up feature by
feature. you lose the sense that someone was using a particular
dialect (language version).
... The intent is to outlaw declarations that a document is HTML 4
(etc)
... Rewriting history is absurd. That's what I think the TAG
response should be
ht: Is there any precedent for this? Has something like this
happened before?
<ht> ACTION: Henry S. to draft for tag@w3.org proposed TAG feedback
on the text/html media type registration in the 25 September draft
of HTML5 recorded in [64]http://www.w3.org/2009/09/25-tagmem-irc]
[64] http://www.w3.org/2009/09/25-tagmem-irc
<trackbot> Created ACTION-316 - S. to draft for tag@w3.org proposed
TAG feedback on the text/html media type registration in the 25
September draft of HTML5 [on Henry S. Thompson - due 2009-10-02].
<masinter>
[65]http://lists.w3.org/Archives/Public/public-html/2009Aug/1184.htm
l
[65]
http://lists.w3.org/Archives/Public/public-html/2009Aug/1184.html
<masinter> ... The main thing that needs updating is the removal of
the permission for sending syntactic profiles of XML as text/html.
In addition, the encoding considerations, fragment identifier
definition, and the text about recognising HTML documents are
somewhat out of date and can be significantly improved by
referencing HTML5 now. RFC2854 is quite vague in a number of areas,
also, which can be cleaned up with an update.
Geolocation/Geopriv
Thomas Roessler is joining us.
<noahm> The chair thanks Thomas Roessler for joining us on short
notice.
lm: I'm interested in current status. I met with Eve in Stockhom,
area directors, what is the IETF and Cisco and CDT response?
tr: I'm not the team contact, this info may be outdated...
... Comment was sent by IETF chair
... "We are working on the comments, something will be given"
... AFAIK they just haven't answered yet
<DanC_>
[66]http://lists.w3.org/Archives/Public/public-geolocation/2009Aug/0
016.html "We're working on drafting formal responses to the Last
Call comments we
[66]
http://lists.w3.org/Archives/Public/public-geolocation/2009Aug/0016.html
<DanC_> have received.
<DanC_> Unfortunately due to vacations this has been taking a bit
longer than we
<DanC_> had expected, but we will have them ready soon."
<johnk> DanC: I agree with this: Most well-intentioned sites,
<johnk> and _all_ evil sites (the ones where privacy leakage is an
issue in the
<johnk> first place) would just ignore the user's requests
<johnk> (and evil sites can just put their own code in there to
ensure that the user's information _is_ leaked)
<DanC_> suggestion: we've looked at the technical issues and a
little bit of the policy issues, and come to the conclusion that
there are several coherent designs and none of them critically in
conflict with web architecture. Maybe let's action somebody to take
the remaining liaison/process issues to the IETF/W3C liaison forum
or something.
<DanC_> (re orthogonality... the device API WG seems likely to
persue that approach)
<johnk> such as [67]http://www.w3.org/2009/policy-ws/cfp.html ?
[67] http://www.w3.org/2009/policy-ws/cfp.html
<johnk>
[68]http://www.w3.org/2008/security-ws/report#PolicyDescription
[68] http://www.w3.org/2008/security-ws/report#PolicyDescription
Adjourned until next time.
Summary of Action Items
[NEW] ACTION: DanC to follow up on best plan for HTML / TPAC
recorded in [69]http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: Henry S. to draft for tag@w3.org proposed TAG feedback
on the text/html media type registration in the 25 September draft
of HTML5 recorded in [70]http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: John to talk to Balisage participants about XML
namespace work, discuss TAG interest in this area, and summarize
recorded in [71]http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: noah Check with Amy on room availability and suggest
to Ian that he mention this meeting in TAG election call for
nominations [recorded in
[72]http://www.w3.org/2009/09/25-tagmem-irc]
[69] http://www.w3.org/2009/09/25-tagmem-irc
[70] http://www.w3.org/2009/09/25-tagmem-irc
[71] http://www.w3.org/2009/09/25-tagmem-irc
[72] http://www.w3.org/2009/09/25-tagmem-irc
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [73]scribe.perl version 1.133
([74]CVS log)
$Date: 2009/10/13 21:41:59 $
[73] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[74] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 16 October 2009 20:36:56 UTC