See also: IRC log
<edit> scribenick: dorchard
<edit> scribe: dorchard
<Stuart> in the circumstance where the HTML and RDF are representations of the *same* description
<DanC_lap> (I'd rather not generalize to "in circumstances...")
<timbl_> In the case in which the HTML abnd RDF documents contain te same infromation (generated from eht sam graph), does the group agrre that it is better to 303 to a generic resourtces whcih is then connegged (wiht URIs for the speific RDF and HTML versions in content-location) than to do a conneg-aqffected variable 303?
<noah> Hmm, I see Stuart as limiting it to "at most in circumstances where...", not generalizing.
<timbl_> In the case (like dbpedia.org/resource/Paris) in which the HTML abnd RDF documents contain te same infromation (generated from eht sam graph), does the group agrre that it is better to 303 to a generic resourtces whcih is then connegged (wiht URIs for the speific RDF and HTML versions in content-location) than to do a conneg-aqffected variable 303?
<noah> I'm fine with what Tim proposes.
<Norm> +1
<DanC_lap> (I don't see /Paris in http://www.w3.org/TR/cooluris/ )
<DanC_lap> (I'd really like our decision to regard an example from http://www.w3.org/TR/cooluris/ so that we can tell when they've made the relevant change)
skw: what if the rdf and html have different information, then is redirect to different based on conneg is ok.
tbl: yes
dorchard: (yay, I even understood this)
<DanC_lap> http://www.w3.org/TR/cooluris/
danc: where in the cooluris do they do this?
<DanC_lap> sectionj 5 http://www.w3.org/TR/cooluris/#examples http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759
group: section 5, the D2R server examples.
<DanC_lap> I think the change is (also?) in http://www.example.com/id/alice
tbl: it mentions the 303 solution, which is described earlier, in the id/alice picture
danc: would like the id/alice diagram different
they don't say whether the html and rdf are the same or not
noah: a proposed gpn is:
... if something is a generic resource (stopped by Danc)
<ht_vancouver> Point of fact: http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759 deals _different_ 303 responses depending on Accept: application/rdf+xml or not
<DanC_lap> .
<DanC_lap> .
<DanC_lap> .
<DanC_lap> PROPOSED: In the case (like http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759 http://www.example.com/people/alice dbpedia.org/resource/Paris) in which the HTML and RDF documents are generated from the same data, that it is better to 303 to a generic resource which is then negotiated (with URIs for the speific RDF and HTML versions in content-location) than to have the 303 response give different URI (paths) depending on content negotiation.
<Norm> ScribeNick: Norm
Henry: I endorse that.
Stuart: I'll endorse that.
<DanC_lap> +1
<timbl_> +1
Norm: +1
<AshokMalhotra> +1
<jar> +1
<dorchard> +1
<dorchard> scribenick: dorchard
<timbl_> [Stuart outs the question]
skw: any objections?
raman: I'm confused...
<timbl_> No objections.
no objections
skw: any abstentions
no abstentions
skw: carried
... TBL has TAG support for the proposed comment
<scribe> ACTION: Tim to convey to the authors of the SWEO group the TAG's resolution [recorded in http://www.w3.org/2008/02/28-tagmem-irc]
<trackbot-ng> Created ACTION-117 - Convey to the authors of the SWEO group the TAG's resolution [on Tim Berners-Lee - due 2008-03-06].
<Zakim> DanC_lap, you wanted to ask which section of http://www.w3.org/TR/cooluris/ tim's proposal regards
ashok: if it's not generated from the same source, then they can use different URIs?
discussions about whether to talk about that questions..
<DanC_lap> agenda order is 2, 3, 7, 6, 4, 5
http://www.w3.org/2001/tag/doc/hash-in-url
<raman> http://www.w3.org/2001/tag/doc/hash-in-url.html
ashok: 2 years ago there was in issue in WS-Addressing about passing parameters.
raman: I haven't looked into that
... the # hack is being used quite widely
... there has been lots of work on server side identifiers, not much on client side
... walks through section 2.1
... interesting point is that each cnn video has URIs that look like /video/
the /video representation contains javascript which then looks at the info after the #
<DanC_lap> (I wonder where this fits in the W3C video workshop report...)
scribe: the action of clicking on the link set the location
... the javascript uses an iframe to prevent media player pop-up.
noah: eventually there is a URI generated and passed to the media player
<DanC_lap> (hmm... http://www.w3.org/2007/08/video/report.html#Addressing_into_Video_content seems to talk about issues that aren't all that closely related)
raman: the address bar of the media player returns an actual URI
what is the URI for cnn?
raman: mms: or other form.
... you can run into problems if the doc has the same fragment id
... such as in mashups
jar: does this ever happen?
raman: not on google, but the mashup could.
<DanC_lap> (I hope google continues to not evaluate javascript at crawl time, since it discourages people from hiding stuff behind javascript)
raman: because of this idiom, the reprensentations are opaquely persistent so no way of permanently indexing.
... comes back to deep-linking problem.
... have to re-engineer the URI by hand to play.
... in fact, some of them are doing this on purpose.
<Zakim> timbl_, you wanted to connect to rest service description languages.
tbl: if I didn't want to obscure and I wanted to index, one way would be to publish information on how a URI is built up.
... reminds me of the REST based description languages.
raman: the code in the client could easily have could have been done on the server.
<DanC_lap> (on "where is the restful web service description movement?" there's still a significant "you aren't gonna need it" that seems to get as much airtime as forward progress)
they could do both, the client side for browser interaction, and a server-side for indexing.
raman: yes
noah: they could do a SMIL doc too.
raman: NPR does this.
<Zakim> noah, you wanted to mention connection to self-describing web & least power
noah: connections between self-describing web and least power
... this uses javascript to do mapping, which is very not least power.
<timbl_> +1 to 'where you can be declarative' being the main pricipal being violated here
raman: least power is related, can't do static analysis.
... basic building blocks are that the web works for you whether your are a browser or not.
... Now the algorithm is even browser specific..
... this is a serious breakage on how to compute reasonably.
... I run software where you open a socket to firefox and see how it generates a DOM.
<Zakim> timbl_, you wanted to complain about frames being the wrong way outå
tbl: when people give a URI of the thing that plays video, the frames are inside out.
... if HTML had in it a decoration tag instead of a frame tag then the URI that you see is the main thing.
<DanC_lap> (yes, frames are inside-out; I saw a talk by Eric Meyer about IE7 support for a rightside-in construct... header/footer or some such)
raman: there was a draft impl of xframes. Let's say it has 3 frames a, b, c.
... look for the example in xframes
<timbl_> http://....../myframes.html?a=ur1; b=ur2;c=rui3
dorchard: I heard him say # in there tbl
tbl: I want a page that looks like the video in the middle, on the left side is all the tracks, on the top is the video controls, on the right is the ads.
... on the whole thing the SMIL that says the thing that is indexed is the video.
<Zakim> Stuart, you wanted to ask about interpretation of #frag in context of returned media type
skw: are you wanting review comments on this draft?
raman: what would be most useful is more use cases on the web
... contributions, even in rough form, would be useful
tbl: the tabulator does this..
raman: would like some TAG review
skw: the interpretation has been typically governed by the media-type.
... this throws that way out the window
... either the architecture is wrong..
<DanC_lap> (which pratice chucks architecture out the window?)
raman: neither architecture nor practice is wrong
... they are discovering the wriggle room
<Zakim> DanC_lap, you wanted to ask about communitites to reach out to
<timbl_> I don't think this throws the architecture out the window
<timbl_> I hink it builds on it
<timbl_> But how can we regard what has been build as part of the web and use i, bookmark it, index it etc?
danc: places I've run into where the entire site navigation done in javascript and can't bookmark.
raman: the google webmaster forum describes that javascript won't happen.
... and why we use sitemap
<Stuart> ftr: the chucks webarch out the window related to: tradional interpretation of frag id is scope by media-type. The kind of practice that Raman reports "throws that out the window".
tbl: this is better than where there is nothing in the URI at all.
... the cnn/video#.... is better than cnn/video#
ht: they ignoring the statement that the media type says governs the interpretation
danc: when you say URL do you include the # and anything after
raman: ..... yes
tbl: you could argue this is a comment on the media-type registration process
ht: index.html#bar, and the doc has <a name="bar"/> and a javascript where bar means a video thingy
tbl: you can just say the programmer is talking to himself
again, it may be more programmers through mashups
<Zakim> timbl_, you wanted to point out that putting itnto th #fragid is actuallty betterthan not putting it anywhere at akll,it addreses bookmarability. This is an attempt to work with
norm: you could use / as well
raman: this is done on the server then
norm: but you could also do this on the client too.
<Norm> Everything about video#/path/to/stuff could have been done as video/path/to/stuff with no substantial difference
(I note the use of URI templates in the client could have used /)
tbl: this is a nested architecture, where you are loading parameter
... what are the breakages?
raman: to make client side and server side parameters symmetric is that nobody says whether you can have more than one # in the client.
<Stuart> ?
raman: you'd want 2 # signs for frames
noah: in google maps the URI doesn't change, but if you click the link to this page you get a link with a URI that links to everything interesting
... in your finding do you 1) intend to cover this class of applications and 2) should we give some guidance to browser vendors over time?
<Zakim> noah, you wanted to ask if this finding gets extended to apps like google maps and the relationship to the browser
noah: for example, the browser in a standard way allowing the app to update the address bar
raman: 1) yes, making the back button do the right thing;
... 2) that is something that should be speced as part of HTML5 dom
... there should some reliable way of accessing javascript array in an interoperable way
noah: one thing that's come up in the same space is portal applications.
raman: covered in next sections on proxies
noah: there is a view of portals that you have approximated the browser looking at 5-10 different app.
raman: That way of looking at a portal is an old way, the client knows it's looking at 5-10 things.
noah: none of the common clients, like ie or firefox, there is no standard navigation for these
... ie, go through weather and then hit back and the browser blows up
... do the browsers have to evolve
raman: I don't think the TAG should write recommendations to browsers.
... browsers will say we don't know what we're talking about
... we know they will do this because they did this already
on what did they do this?
raman: look at David Baron's response, on http ping
... he said we don't know what we're talking about.
<Zakim> Norm, you wanted to point out Mark Birbeck's work in this space of "parameters"
<DanC_lap> "I
<DanC_lap> don't think the TAG has the necessary experience in user-interface
<DanC_lap> design." -- Baron http://lists.w3.org/Archives/Public/www-tag/2008Jan/0036.html
norm: this reminds me of mark birbeck's sidewinder
raman: that's covered later
<DanC_lap> trackbot-ng, status
<DanC_lap> ACTION: T.V. call for review of "Usage Patterns For Client-Side URL parameters" draft finding after collecting any input for a week [recorded in http://www.w3.org/2008/02/28-tagmem-irc]
<trackbot-ng> Created ACTION-118 - Call for review of \"Usage Patterns For Client-Side URL parameters\" draft finding after collecting any input for a week [on T.V. Raman - due 2008-03-06].
ashok: this document is 3 or 4 uses. This doesn't have "this is wrong". When people reviewing this, how will we fill in section 4
<DanC_lap> ACTION: Henry S. review of "Usage Patterns For Client-Side URL parameters" , preferably this week [recorded in http://www.w3.org/2008/02/28-tagmem-irc]
<trackbot-ng> Created ACTION-119 - S. review of \"Usage Patterns For Client-Side URL parameters\" , preferably this week [on Henry S. Thompson - due 2008-03-06].
raman: there is a 2 step process. first, get all the patterns.
<DanC_lap> ACTION: Dan review of "Usage Patterns For Client-Side URL parameters" , preferably this week [recorded in http://www.w3.org/2008/02/28-tagmem-irc]
<trackbot-ng> Created ACTION-120 - Review of \"Usage Patterns For Client-Side URL parameters\" , preferably this week [on Dan Connolly - due 2008-03-06].
raman: if there are in conflict, then that will be obvious. If they aren't in conflict then there's no problem. either way is good.
... how to beat www-tag bush, we need to try other communities.
... also what difficulties
<AshokMalhotra> scribenick: AshokMalhotra
Jar:Jar: I want to avoid the situation where we make a lot of effort then drop to TAG for review and there is some disruption in the process. I would like TAG to say "there is a chance something like this could find its way into WebArch, CoolURIs"?
... One solution is link foo rel= ' There are other possible solutions. Solution to httpRedirections-57.
NM: I don't thik you will get assurance you want.
<DanC_lap> previous discussion of Link under issue 57: http://www.w3.org/2008/02/21-tagmem-minutes#item03
SKW: Direction is a header that describes the resource. Henry had some reservations. Looking at Finding Resource Descriptions. Describes a number of possible solutions to the problem. We are aware of some activity in the http-bis WG.
<DanC_lap> http://www.ietf.org/html.charters/httpbis-charter.html
DO: Mark Nottingham was wondering if there should be a workshop on this issue?
JAR: Under what aegis should this happen?
TimBL: Talk to Ralph Swick.
SKW: There is ongoing liaison with IETF
HT: There is a WebArch issue here. I would encourage JAR to organize and write about, No matter who takes it on in long run.
JAR: There are a number of people not on TAG who care about this issue. Where should we have this conversation?
<Zakim> DanC_lap, you wanted to clarify that there isn't "ongoing liaisons with the IETF" in any particular way
JAR: I would like the POWDER folks involved.
DanC: There is no liasion with IETF on this. http-bis chair has said this will not happen in that WG.
<timbl_> You Ccc everyone you know to be interested in it. You try to make sure group s who whould be involved are. Same with people. You can do it as an email set of Cc: addresses, until you then look at the CofMass of the group, and spawn something at the closest socially appropriate body.
<timbl_> http://esw.w3.org/topic/LinkHeader
DanC: Maybe AWWSW WG?
<Zakim> timbl_, you wanted to mention that John Klensin mentioned a possible independent track for the link headers
TimBL: Here is a possible role for TAG. POWDER needs this functionality. We can also point out others who need it.
<DanC_lap> +1 use cases for link-header-or-something-like-it
TAG should write something that draws in all these usecases
<DanC_lap> +1 draft use cases for link-header-or-something-like-it
SKW: Tag can write a discussion document and recommend IETF take it up
<Zakim> ht_vancouver, you wanted to mention other places to look for work on Uniform Access to Metadata
<DanC_lap> HT: this problem is worked on elsewhere under the name "uniform access to metadata" in XRI, and under a similar name in ARK work
<timbl_> ACTION: Henry to severely criticize the stone-age line-end non-unicode Ark format for metadata to its source.
<trackbot-ng> Sorry, couldn't find user - Henry\
<ht_vancouver> ACTION: Henry S. to draft TAG input to review of draft ARK RFC
<trackbot-ng> Created ACTION-121 - S. to draft TAG input to review of draft ARK RFC [on Henry S. Thompson - due 2008-03-06].
<DanC_lap> trackbot-ng, status
<DanC_lap> ? ACTION: Jonathan to call for interest in www-tag (among other places) in link-header-or-something-like-it
<DanC_lap> ACTION: Jonathan to call for interest in www-tag (among other places) in link-header-or-something-like-it
<trackbot-ng> Created ACTION-122 - Call for interest in www-tag (among other places) in link-header-or-something-like-it [on Jonathan Rees - due 2008-03-06].
End of httpRedirections-57 Agenda Item
HT: On Tuesday Tim said we need to discuss role of validation in Tagsoup integration.
TimBL: Dave has stated that Roy has argued for the HTML spec to only deal with markup.
<ht_vancouver> (HST thinks Roy hasn't gone far enough, I think Crockford is right: http://www.crockford.com/html/ )
<DanC_lap> fielding's exact words: "This draft has almost nothing to do with HTML. It is a treatise on browser behavior. That is a fine standard to have, but deserves a different title so that the folks who just want to implement HTML can do so without any of this operational/DOM nonsense." -- http://www.w3.org/2002/09/wbs/40318/wd11spec/results
<timbl_> I am sympathetic to an alternative way of breaking up the HTM spec in whcih eth DOM and markup for each eleent are kept together.
<Zakim> ht_vancouver, you wanted to suggest adding HTML leaking out into XML contexts
<DanC_lap> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Feb/0132.html
<DanC_lap> I think they know how to fill in the follow-your-nose path, to wit: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Feb/0135.html
<DanC_lap> TimBL: there are two self-describing-web stories: (1) start from webarch and normative references; so RDFa would have to get cited somewhere (2) if enough people agree, you're done, a la microformats. [guerrilla standaridization]
<noah> scribenick: noah
TB: I read Noah in self describing Web as saying saying that community consensus was sufficient and that 'follow your nose' didn't necessarily depend on specs.
NM: Wow. I completely agree that having community consensus may be necessary, but I thought the Self-Describing Web draft made clear that it's nowhere near sufficient. Self-describing Web intends to make very clear that you MUST have rigorous specs and that you must be plugged into THE algorithm of the Web.
TBL: Don't see the MUST.
NM: Fair enough. We've already agreed we need to think about the possible value of using MUST of some of Self-Describing Web.
DC: The relevance of RDFa to Tag Soup is: to what extent do we need one giant HTML group to make things like RDFa real? I'm concerned that I think Ben Adida might want RDFa parsed unconditionally, regardless of follow your nose.
TBL: I think he wants it in the spec.
DC: What's an improvement on the RDFa situation? Hmm. It was somewhat independently developed.
NW: I need some means of saying that I assert I am using it. Profile would be fine. Without profile, you don't have standing to interpret these things.
DC: By the way, the HTML 5 spec doesn't have a profile attribute.
NM: Is profile one of those things that have architectural benefit, but which the community is telling us they don't think wins on >short term< cost benefit?
DC: Great question. Maybe we should discuss another time rather than now.
Various: yes.
<dorchard> http://www.intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility
TVR: Maybe we should talk about Sam Ruby's proposal? ( http://www.intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility )
<dorchard> http://www.crockford.com/html/
HT: Dan, have you looked at Doug Crockford's proposal ( http://www.crockford.com/html/ ) ? I thought it directly responded in a positive way to the decisions we made about XHTML 2 and HTML 5. We heard at that time from people who felt that XHTML was valuable. I think Doug's proposal pointed in a productive direction.
DO: Why is the version attribute better than ??? being proposed in <HEAD>. Never mind, I'm thinking of what the IE folks are doing.
Several: Nope, different, though in a related space.
NM: Why would XHTML folks like this?
HT: Just seemed to be conciliatory.
NM: Does it allow for or require XML syntax?
HT: Not sure.
NM: Seems pretty fundamental to the XHTML story.
DC: I'm doubtful browser vendors will implement the proposal on implementing per the HTML v4 specification. I do think the version approach instead of DOCTYPE feels somewhat good: <!DOCTYPE html> puts it in "not quirks" mode
NM: Will the IE people, who have their own long story on quirks, like this?
TVR: Don't think so.
DC: I think IE does reasonable things with this.
TVR: I think Webkit and Safari trigger HTML 5 parsing with this. Note I said only parsing, not all the other HTML 5 stuff.
DC: Raman, have you looked carefully at the must ignore formulation in HTML 5?
TVR: Did at one point, but not necessarily recently.
<Stuart> http://www.quirksmode.org/
DC: The 200 test cases are interesting. The rule seems weird. Random attributes end up in the DOM. Random tags wind up in the DOM, typically as empty.
... <div> <banana> .... </banana> </div>
... I think this leads to in the DOM <div> <banana />......<some kind of magic end-only banana tag> </div>
... (back to reading from Doug) One language on a page. In part to allow for new secure language. Hmmm. Not sure that 2nd bit will happen in my lifetime.
... <script> tags are not immediately implemented. Could we really get there?
HT: I think people would use this if we spec'd it.
DC: How?
NM: Why would browser vendors be motivated to do this?
HT: Some vendor might be motivated to do this first. Otherw would then follow.
NM: Not convinced, unless there's user or other benefit that the browser vendors value.
SW: Does Doug participate in the working group?
<Zakim> stuart, you wanted to ask if crockford participates in the wg
HT: I believe Yahoo does not participate in any W3C WGs, due to concerns (or possibly misunderstandings) about the patent policy.
<Zakim> timbl_, you wanted to eh? and to ask how rtis solves ny problems
SW: I think it would be valuable for him to make this input to the group.
DC: The group has seen it.
TBL: How would this help?
HT: I believe I could define an algorithmic transformation to the script tag.
NM: Why?
HT: No more document.write eliminates ambiguity and complexity.
NM: Ah, that makes sense.
<Stuart> q>
<Zakim> DanC_lap, you wanted to say HTML is more about economics and transition than clean design
NM: Gee the idea of just getting rid of document.write seems big. Would the world really buy a restriction to no document.write?
DC: You're right, self-modifying code is a source of major problems. But I doubt people will give up on it. Is Google Ads dependent on that?
TVR: I think that was true in the IE5 timeframe. Less convinced that's true now.
DC: OK, that particular case might not be so troublesome. Raman, do you know the details?
TVR: Only in some contexts.
HT: Someone else talked a few months about a clean Javascript movement. Anyone know?
Silence.
<Zakim> dorchard, you wanted to say that I directly solicited Crockford to join WAF for Access control
DO: There was a conference here a few months ago which explored all the problems with the existing stuff. Got some attention.
<dorchard> He presented http://javascript.crockford.com/security.ppt
<Zakim> ht_vancouver, you wanted to try to remember the 'clean javascript' movement
DO: I talked to him about joining the Web Application formats group.
<Zakim> noah, you wanted to ask more about document.write
<dorchard> Here's Crockford's slides on the web http://www.slideshare.net/douglascrockford/ajax-security-255587
NM: Would TAG focus on document.write be helpful to the community?
<dorchard> Note the slide 40 on JSLint: A JS L int option. • It defines a safe HTM L /JavaS cript subset. • Removes from JavaS cript all features that are unsafe or suspect. • A llows foreign ads and widgets to safely interact.
TVR: There is a balancing act between "it's evil" and "it's being widely done". Not clear that the community is getting the balance right. Some of it is about, starting now, not building new stuff on this model.
<Zakim> DanC_lap, you wanted to ask timbl to show us how the tabulator imports modules
NM: Seems to me the question is: can you get to a mode where you say declaratively "In this version of HTML, or with this switch, you should fault if you see document.write"? Just saying "all the calls to document.write are attributable to old specs" doesn't help. You want to encourage a class of content that's clean, and you want to identify the content that is provably clean (I.e. because you'd fault on unclean constructs if they showed up). Of course, browsers will have to support a mode with document.write for a long time.
DC: Part of the problem is that Javascript doesn't have import. See also the Yahoo UI toolkit.
<Stuart> FWIW someone asked earlier for a pointer to Sam Ruby's article: http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility
<DanC_lap> i get lots of relevant hits for "javascript import" at http://www.google.ca/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=oUX&q=javascript+import+write&btnG=Search&meta=
<DanC_lap> but I can't follow the links
<timbl_> function include(linkstr){
<timbl_> var lnk = document.createElement('script');
<timbl_> lnk.setAttribute('type', 'text/javascript');
<timbl_> lnk.setAttribute('src', linkstr);
<timbl_> //TODO:This needs to be fixed or no longer used.
<timbl_> //document.getElementsByTagName('head')[0].appendChild(lnk);
<timbl_> return lnk;
<timbl_> }
<timbl_> http://dig.csail.mit.edu/2005/ajar/ajaw/js/util.js
<ht_vancouver> Something TVR just said reminds me of what makes my blood pressure rise: major structural aspects of the HTML5 design are being driven by the need to accommodate what all thoughtful HTML authors agree is bad HTML, .i.e. inline document.write
DC: Javascript itself is being revised. Seems there's a lot of focus on import.
HT: Yes.
<raman> document.write ('<scr' +'ipt>' + '...')
<raman> the above is backquote in lisp
<noah_> Cute
<Norm> +1 to ht_vancouver's comment
<timbl_> myNode.innerHTML="<em>Careful!";
<timbl_> myNode.innerHTML="<em>Careful!</em>";
DC: Around the table wrapup, starting with Raman.
<timbl_> 4.13 NODLIN(4.13) = NODLIN(4.13) + ";PRINT "HELLO WORLD; EXEC(NODLIN(4.13"
TVR: The most worthwhile impact from the TAG will be to help the world understand a) how outside developments like RDFa can get incorporated into HTML without going through a central WG and b) how can developments in HTML work properly into the non-HTML parts of the stack.
<timbl_> Nodal was a delightfully self-modifying language.
NW: I think some of the HTML 5 design are bad engineering. I'd love to stand up and say that, but doing so may be impractically socially.
DC: Such as?
NW: Well, a large monolithic specification isn't necessarily good. I'd also like to get rid of the non-XML serialization, or failing that, find a way to get Namespaces into the non-XML serializations.
DO: More or less agree with Norm. Getting namespace integration right would be good. Sam Ruby's idea might be good. Versioning issue with HTML is wide open. I'm starting to understand Doug Crockford's point about security, but not clear how to get from here to there.
NM: I think the real challenge for us is finding the bits of this where we can actually help and lend some insight that will be truly helpful to the community.
SW: Distributed extensibility is important. There's a social problem regarding interacting usefully with people in the WGs. Doing useful reviews of their specificatins may be a good way to be helpful. A lot of work given that the specs. in question are large.
JR: pass
HT: Making the case that there's real value in the XML serialization is important to me. The ability to specify a simple algorithmic transformation between conforming forms on both sides would be a big help. That's why document.write has got to go.
DC: I thought I heard volunteers to help with distributed extensibility and namespaces. Likewise I heard offers on social issues. I think Raman's two points are good and useful points of focus for us.
<DanC_lap> DC: I think looking at specific cases of the two points (RDFa, ARIA, SVG,MathML, SVG, ...) is a good use of tiem
<ht_vancouver> HST has found what he was trying to refer to 30 minutes ago: it's called Unobtrusive Javascript: http://en.wikipedia.org/wiki/Unobtrusive_JavaScript
TBL: I feel that the role of the TAG is in some ways similar to the IESG's in the IETF. That's in part to promote principles that are in some ways obvious, but too often missed. The TAG's voice is heard. The TAG should take the time to write down the things that they think are important. E.g. making the case clearly as to why self-modifying code is bad. Focussing on the DOM might be another example. It may be interesting to find out how many people out there agree and will rally around these important points.
AM: I think Doug Crockford's writeup makes some points really well.
<DanC_lap> RESOLVED: to thank the host, with applause
SW: I would like to expand on the thanks given to our host earlier. Not only was the dinner terrific, but he's done a great job of hosting all around.
<timbl_> High CO2 levels lead to feelings of stress
<DanC_lap> ashok, see http://dig.csail.mit.edu/2007/id/talk19