TAG Sep 2009 meeting in Cambridge, MA

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: 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 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: 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 :) ...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> http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt

<noahm> 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 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> http://dev.w3.org/html5/spec/Overview.html has reference [PSL]

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> 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 (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 http://www.w3.org/TR/xml/. Implementations may follow the edition cited an

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> 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: 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

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> http://phonegap.pbworks.com/JavaScript-API shows an accelerometer JS API, for example

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> 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> 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

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