See also: IRC log
<jkemp> scribe: John Kemp
<jkemp> scribenick: jkemp
nm: (reviews "review goals" +
... 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)
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
... 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
... 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
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
... 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.
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
<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)
issues 7,13,15 get the most votes
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
... 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: 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)
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?
<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.
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
... 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
... 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
... 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
... 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
... 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
... 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
... 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].
<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
... 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
... 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
... 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
ht: XPath and XSLT changes in HTML are issues
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
... 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
... 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
nm: some of the approaches we're tempted to recommend for error recovery don't work for things like document.write
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
... 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
<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
review of JK document
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
... 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
nm: maybe standardizing way
temperature is embedded in a URI or query string ... seems
... 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?
lm: question about extensibility of GeoLocation to civic location
lm: where are the guidelines for
writing extensible API specifications?
... discussion of whether TAG should give guidelines ....
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
privacy & security in APIs?
scribe: discussion of geopriv, policy
... 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
... (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/
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
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
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