See also: IRC log
<Norm> Scribe: Norm
<DanC> (oops; html wg telcon going long again... hmm...)
<scribe> ScribeNick: Norm
<scribe> Agenda: http://www.w3.org/2001/tag/2008/04/17-agenda
Ashok: Did we send out our XRI comments?
Stuart: We sent them, they did
respond. It's under agenda item 4 this week.
... We haven't discussed it yet.
... One other item: I have updated a report of our activities for
the AC meeting.
SKW: Accept minutes of 10 Apr?
<Norm_> minutes 10 Apr
so RESOLVED.
RESOLUTION: Next meeting 1 May 2008. Noah to scribe.
<raman> zakim isn't picking up
Jonathan: Following Dan's request, I
tried to collect use cases. Didn't hear back from as many as I
would have liked.
... There's enough to go with.
<Norm_> Use cases section of in Finding Resource Descriptions topic
Jonathan: I want to write a summary
of each of those and why they want to use the link header.
... Assuming that the use cases look good, I'll also try to talk
about solutions in a neutral way.
... It'd be good to have some discussion of this at the f2f.
... I'll send out something and try to solicit some reviewers.
Stuart: Which document?
Jonathan: There's no document yet,
but there will be one based on this wiki page.
... Phil Archer would like to have something published by June.
Stuart: He'd like to have some confidence that if they decide to use the link header to find POWDER descriptions, that the TAG would object.
<scribe> ACTION: Henry S to find out what Jonathan would like Henry to do with respect to this document and do it. [recorded in http://www.w3.org/2008/04/17-tagmem-minutes.html#action01]
<trackbot-ng> Created ACTION-137 - S to find out what Jonathan would like Henry to do with respect to this document and do it. [on Henry S. Thompson - due 2008-04-24].
<scribe> Scribe: Dan Connolly
<DanC> scribenick: DanC
close ACTION-136
<trackbot-ng> ACTION-136 Liaise with michael cooper on their expectations of the TAG closed
SKW: last week we seemed near a decision... so close and yet so far...
HT: I studied the hyphen-based
approach last week... (http://lists.w3.org/Archives/Public/www-tag/2008Apr/0229.html
) ...
... esp by studying the arguments against the :-based approach
<ht> http://www.w3.org/2008/03/aria-implementation
HT: found Cooper's http://www.w3.org/2008/03/aria-implementation helpful...
<ht> http://simon.html5.org/test/aria/colon-vs-dash/
<Stuart> Simon Pieters
HT: I found some false negatives; not sure how much that changes the argument...
<ht> http://www.w3.org/XML/2008/04/colon-test.html
HT: in response to my work (http://www.w3.org/XML/2008/04/colon-test.html ) I see supportive reply from Reschke [sp?] and disagreement from Pieters
<Stuart> For multibrowser screen shots see: http://browsershots.org/http://www.w3.org/XML/2008/04/colon-test.html
HT: none of the solutions is very
elegant; it's all about trade-offs...
... the hyphen approach has small cost forimplementators, high cost
for authors; cost of colon approach ismodest for implementators,
zero for authors
... "orthogonal extensions to HTML will be done by stakeing out
arbitrary parts of the symbol space" concerns me as an approach
TVR: indeed, that's a big
concern
... yes, legacy support is important, but giving it *so* much
weight in the design bodes poorly for the future.
<Zakim> DanC, you wanted to ask how the colon approach has zero cost for authors and to ask if ARIA is really orthogonal
DanC: doesn't the colon approach burden authors with namespace declarations?
HT: no; the aria: prefix is fixed, but it allows the same syntax to be used in XHTML
NDW: yes, the concern I see with the hyphen-approach is the precedent it sets for future extensions to HTML
DO: there's a constituency, led by Ian Hickson, who considers distributed extensibility a bug, not a feature; witness the design for integrating SVG and MathML into HTML
<Zakim> DanC, you wanted to ask DaveO and others to look at the cost of distributed extensibility from the content developer's perspective
DanC: there's a cost to distributed extensibility too...
<ht> DanC: The really nice thing about HTML is not just the pointy brackets, but the consensus about the meaning of the tags
DaveO: there's a lot of SVG and
MathML content; to say "never mind all that design/standardization;
we're going to throw that out and make a new design"; I don't think
that's a great way forward.
... the HTML 5 draft subsetted SVG and MathML
... maybe we just need to acknowledge the need to make namespaces
simpler.
<Zakim> ht, you wanted to identify the value of the distributed story
DaveO: maybe implicit namespace
declarations... along with some tweaks to XML...
... would be the right approach, rather than having browser devs
and the HTML WG be the gatekeepers of the future of the web
HT: IE's namespace stuff has its
quirks, but it did enable a form of dispatch that supports
distributed extensibility
... when [in March 2007] we announced a new plan for work on HTML
and stopped saying "HTML is going to be replaced", a significant
community said "HEY! you just pulled the rug out from under our
investment in XHTML"
<Zakim> raman, you wanted to point out that the people making the concensus on the subset set of tags are not the experts in the language
HT: this constinuency that can't abide namespaces... why is it that they can't?
DC: I don't know; I don't share their opinion, but I know they're out there.
<Zakim> Stuart, you wanted to mention Hixie comments from http://lists.w3.org/Archives/Public/public-html/2008Apr/0205.html
<Stuart> In any case, the syntax part would be a very minor part of any such
<Stuart> effort. Adding new user-agent-supported vocabularies requires significant
<Stuart> investment:
<Stuart> ...
<Stuart> * describing the syntax
<Stuart> * describing the semantics
<Stuart> * describing the behaviour
<Stuart> * defining the error handling for syntax errors
<Stuart> * defining the error handling for semantic errors
<Stuart> * implementing the defined features
<Stuart> ...
TVR: the re-design of SVG and MathML is short-sighted and puts at risk the independent development of those languages [rather poor paraphrase, sorry]
<raman> scribe lost the gist of most of what I said, sigh.
SKW: I have some sympathy for the point that "the syntax is the small part of deploying new web markup features", but ...
<raman> I've written those thoughts too many times in too many places, not sure if it's worth the finger energy typing it in here
TimBL joins...
TVR: (1) it's not just that the HTML 5 design subsetted SVG and MathML...
[scribe struggles to follow TVR]
(2) the HTML parsing rules leak
DO: indeed, this suggests that languages designed apart from HTML will die
TVR: if it were just that, I'd say
OK, the market has come up with something that works. but it's
worse than that; it takes us back to the 1996 tag wars
... namespaces and browser extensions democratize the idea
marketplace
<Zakim> DanC, you wanted to wonder whether the relevant parties are motivated to work in the direction DaveO suggested
TVR: but that's not where we are now, and the leakage of the parsing algorithm is the biggest blocker
DanC: DO suggested some possible ways
of helping with namespace authoring pain.
... I can see the appeal, but you have to step back pretty far to
see it
... Finding the people who will pay is where I run into trouble
<raman> Dan, re: the html parsing rules leak:
<raman> As mathML and SVG integration rules in html 5 are being defined, the html5 parsing rules also apply to the mathml/svg subtree with respect to closing tags etc
<Zakim> timbl, you wanted to ask whether IE application/xhtml ??
DO: IE's namespace support is in some
sense not that new; some of it was in IE7...
... what's new is the way behaviors are assocaited
TimBL: this is in application/xml?
DaveO: no; in text/html
TimBL: in non-quirks mode?
DaveO: not sure
HT: I read in some MS documentation
"we still don't plan to support namespace prefixes on
attributes"
... I gather that since IE6, there's one parser and dom-builder for
HTML; it's been tweaked, but it has never included an XML
parser...
TVR: meanwhile, there's a completely separate XML codepath
HT: and the XML codepath uses a stylesheet and the output goes back into the HTML parser. (or else you get tree mode)
TVR: meanwhile, application/xhtml+xml
[and something about the save-as dialog that I didn't follow]
... there's also a technique for namespace dispatching by e.g. Mark
Birbeck [sp] in a forms player
<timbl> (IE 8 download is only available for windows)
[much swapping in of the state of the art in tagSoup ... rate exceeding scribe's abilities ...]
[I wish more of this background were captured in test cases... I agree with HT that simon's test cases make all the difference in approachability]
SKW/TBL start to poll where we are on aria- and aria: ...
HT attempts to fill TBL in on investigation into aria- and aria:
HT: so I'm inclined to ask WAI PF to
look again at the cost of a single syntax for XML and HTML, given
new info about the cost of aria:
... while that's my inclination, the study I did is recent and
discussion has just started
<ht> Tim, my email to www-tag which sets out my exploration is here: http://lists.w3.org/Archives/Public/www-tag/2008Apr/0229.html
TimBL: I've been thinking about how to get to one stack... and considering a page checker as an experimentation platform
[details raise ETOOFAST]
<raman> tim, would you implement such a checker pre-dom construction or post-dom? everything you've said makes it sound pre-dom
<raman> but I want to be sure.
<ht> TV: Document.write is the problem
TVR: timbl, the design sketch you gave... is it all pre-DOM? keep in mind document.write()
<Zakim> ht, you wanted to mention TagSoup (the parser) and PyXUP
HT: Tim, I'm sympathetic to what I
hear you sketching [?], and it would work if it weren't for
document.write()...
... I'm convinced of the technical feasibility of this approach
based on experience with TagSoup (the parser) and PyXUP, with the
noteable exception of document.write()
<ht> http://www.idealliance.org/papers/extreme/proceedings/html/2007/Thompson01/EML2007Thompson01.html
<ht> "Declarative specification of XML document fixup"
TVR: a two-pass approach is typical in these self-modifying designs. [?]
<ht> While we're on what we want five years out, I also want to re-endorse Doug Crockford's position: http://www.crockford.com/html/
<ht> My problem is that it's easy to _say_ that "aria-" doesn't set a precendent, but that won't keep it from _being_ one
<Ashok> It's not gonna work
more consideration of near term TAG comment on ARIA approach ... inconclusive
TimBL gets some feedback on presentation ideas