See also: IRC log
<trackbot> Date: 07 January 2010
<DanC> Next Meeting: 14 January 2010 Chair: Noah Mendelsohn Future scribes: Jonathan -> John -> Ashok
<Ashok> Liam, can you post pointer to slides?
<DanC> RESOLVED: to approve 3 Dec minutes http://www.w3.org/2001/tag/2009/12/03-minutes
<DanC> (I'll re-assign 215 to me)
<DanC> (since I'm scribing this week)
<DanC> RESOLVED: to approve minutes 17 Dec http://www.w3.org/2001/tag/2009/12/17-minutes
<DanC> close ACTION-362
<trackbot> ACTION-362 Announce TAG ftf minutes 8-10 Dec closed
<DanC> close ACTION-366
<trackbot> ACTION-366 Bring f2f date proposal to group based on poll input and ask Raman and Tim about availability closed
<DanC> "New date for upcoming TAG F2F: 24-26 March 2010 at MIT"
<DanC> close item 2
<DanC> close item 1
<DanC> close item 3
<Liam> proposal :http://www.w3.org/2010/Talks/01-07-liam-namespaces/
<DanC> Unobtrusive Namespaces (slides)
<noah> Henry, as you can hear, we've gone to Liam, but I did just ask whether you had any early news on action-357?
<DanC> LQ: "HTML 5 draft violates layering" e.g. the switch from HTML to SVG namespace is hardwired
<DanC> slide Constraints on solutions
<DanC> slide: Other technologies
<DanC> slide: Proposal: Unobtrusive Namespaces
<masinter> are there two proposals, one "unobtrusive" and another "invisible"?
<DanC> LQ: yes, there two proposals, one "unobtrusive" and another "invisible"
<noah> Welcome, Tim. We're on http://www.w3.org/2010/Talks/01-07-liam-namespaces/#%288%29
<DanC> ACTION-357?
<trackbot> ACTION-357 -- Henry S. Thompson to elaborate the DPD proposal to address comments from #xmlnames and tag f2f discussion of 2009-12-10, particularly wrt integration with XML specs and wrt motivation -- due 2010-01-12 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/357
<noah> Right, Dan. I knew the action wasn't due until next week, but was curious whether HT had any early progress to report. Not sure how I got the date wrong in the agenda.
<DanC> perhaps the date got updated
<DanC> ok. so it's on the slide: <ch.ac.cern.html>
<Zakim> noah, you wanted to ask about two proposals
<DanC> NM: are you just observing 2 ideas? or do you advocate one over the other?
<DanC> LQ: invisible namespaces takes unobtrusive namespaces further, by eliminating the need for a link...
<Zakim> DanC, you wanted to note an unmet static scoping requirement and our requirements/proposals table whiteboard in http://www.w3.org/2001/tag/2009/12/10-tagmem-minutes.html#item03
<masinter> are there pointers to explicit proposals? the slides don't actually cover the proposals but just the claimed attributes of the proposals
<DanC> ... and it's invisible namespaces that I've proposed to the HTML WG
<Liam> (URLs are on slide 5)
<inserted> scribenick: noah
DC: The proposals are cited on slide 4 or 5, I think.
<masinter> see http://www.barefootliam.org/xml/20091111-unobtrusive-namespaces
DC: Neither of these seem to meet
my need for static scoping.
... Without the link, when you're looking at one document, some
other document can change the meaning.
LQ: Already status quo in XML with DTDs
DC: Yup, I don't use those.
... We had a matrix of requirements vs. proposals.
<masinter> don't see pointer to "Invisible Namespaces" proposals
TBL: Where do you draw the line?
DC: You can change the binding between the element shortnames and expanded? names
<jar> timbl: Where do you (Dan) draw the line between static and non-static scoping?
TBL: It's a well defined set of docs that can do that. Isn't that how the Web works.
HT: Maybe another way to say it, is that's confusing for software not humans.
Temp scribe is falling behind...
DC: The widely deployed MIME type doesn't support DTDs for redefining such things.
<DanC> s/Hmm, though perhaps without the link you could trace back.//
<Liam> (a common similar XML example today is the "chameleon schema pattern" too, to define an element pool used in multiple namespaces)
TBL: We already have a situation where things like CSS are required for rendering.
<DanC> TBL: ... clipboard type ...
TBL: We had some sort of cut/paste requirement. So, there must be a clipboard type that carries the fully qualified version to be copied.
<jar> danc: Static = you have to be able to look at the dcument (and no other documents) and be able to map abbreviated form to full URI.
DC: Liam, can you say more about who we're helping?
<inserted> scribenick: DanC
DC: say more about motivating use cases?
LQ: people hand-authoring HTML/XML documents with lots of namespaces at the top...
<masinter> the examples LQ gave weren't "hand-authored"
LQ: e.g. when authoring tools add all the namespaces they might ever use
<timbl> @include "myincludes.h"
DC: I don't find that very motivating
<Zakim> noah, you wanted to say there's a larger question about encouraging use of namespaces
<masinter> i think we should distinguish between "hand authored" and "computer software generated"
<noah> unack noah :-)
<caribou> the include solution will disable content sniffing at least
LQ: there's been a long-standing demand in the XML community for mixing and mashing namespaces
<noah> James Clark blog posting: http://blog.jclark.com/2010/01/xml-namespaces.html
(yes, namespace "macros" were left out of the RDF requirements on the grounds that the functionality could be layered on top, but experience shows: not so.)
<noah> From James: For XML language designers, think whether it is really necessary to use XML Namespaces. Don�t just mindlessly stick everything in a namespace because everybody else does. Using namespaces is not without cost. There is no inherent virtue in forcing users to stick xmlns=��� on the document element.
NM: I think using unqualified
names gives less follow-your-nose/self-describing web.
... so I prefer some way to make namespace syntax less tedious
to getting rid of the URI bindings altogether
<Liam> [ht: removing the prefix from the document element is a good idea]
HT: in the case of a document of one sort with bits of other stuff mixed in, I like that to be visible.
<noah> I also said that, somewhat independent of the merits of Liam's or HT's proposals, the TAG would have an interest in the follow your nose (or lack thereof) characteristics of James' advice.
<Zakim> masinter, you wanted to ask about namespaces for attributes vs. namespaces for elements
<htt> HST does think it's orthogonal
LMM: personally, what I think is most problematic about XML namespaces is the difference between unqualified attribute names, which don't bind to the default namespace, and unqualified element names, which do
<Zakim> Liam, you wanted to clarify that I'm not proposing banning prefixes, only reducing the need for them
LQ: yes, that's problematic, and yes, the [which?] proposal allows you to say "this attribute [of this element?] is in namespace X"
<noah> I think that was the unobtrusive, which in turn covers the invisible case.
<noah> I think that was the unobtrusive, Unobtrusive Namespaces in turn covers the invisible case.
<Zakim> caribou, you wanted to mention "sticky namespaces"
<Liam> carine: sticky namespace, using a prefix introduces a new default namespace beneath it; this is not Henry's or Liam's proposal
<timbl> To make the default prefix change whenever a prefix is used.
<Liam> [sticky namespaces changes the meaning of existing documents]
CB: there is a proposal that
children of an element of an element that has a namespace
prefix would not need a namespace prefix. in a response to HT's
blog item
... it's a big change; not clear that it's cost-effective
<timbl> It would be useful for HTML nested inside SVG inside HTML but it does hange the meaning of existing documents.
<Zakim> MikeSmithX, you wanted to comment of alignment of James Clark blog with positions stated in HTML WG discussions
<caribou> http://www.w3.org/QA/2009/11/default_prefix_declaration.html#c184989
(did jjc make a proposal?)
<timbl> (he blogged)
<noah> From James' Blog:
<noah> My current thinking is that a blend of registry- and DNS-based approaches would be nice. For example, you might have something like this:
<noah> * names consist of one or more components separated by dots;
<noah> * usually names consist of a single component, and their meaning is determined contextually;
<noah> * names consisting of multiple components are used for extensions; the initial component must be registered (the registration process can be as lightweight as adding an entry to a wiki, like WHATWG does HTML5 for rel values);
<noah> * there is a well-known URI for each registered initial component;
<noah> * one registered initial component is �dns�: the remaining components are a reversed DNS name (Mark Nottingham�s had a ID like this for MIME types); there�s some way of resolving such a name into a URI.
<timbl> http://blog.jclark.com/2010/01/xml-namespaces.html
MS: in jjc's blog post, he notes there's use of URIs for things, and for types of things. He suggests using URIs for types of things is more trouble than it's worth.
<noah> Quoting James again:
<noah> From a more theoretical point of view, I think the insistence on URIs for namespaces is paying insufficient attention to the distinction between instances of things and types of things. The Web works as well as it does because there is an extraordinarily large number of instances of things (ie Web pages) and a relatively very small number of types of things (ie MIME types). Completely different considerations apply to naming instances and naming types: bo
<noah> I also have a (not very well substantiated) feeling that using URIs for namespaces tends to increase coupling between XML documents and their processing. An example is that people tend to assume that you can determine the XML schema for a document just by looking at the namespace URI of the document element.
<masinter> ISO OIDs used the same kind of name for things and for types of things. There's a long history of having a way of assigning names without having to distinguish between whether it's a 'type'
MS: what jjc suggests, i.e. not using prefixes, and using reverse DNS and/or a registry, is a position supported by various HTML WG members and Micah's proposal.
<noah> Mike, you said "not using prefix" but I think you also meant "not using URI", which is probably the deeper architectural change on the Web.
<htt> HST agrees with Liam that no proposal which rebuilds XML names will not fly
<masinter> if people don't like having the URI for a namespace be resolvable, use URIs of the form "urn:" for the namespace
<noah> Heads up, I'm getting ready to wrap up this agenda item.
<htt> James's blog is addressing the question of what a _new_ language should do about names
<noah> It seems pertinent to me that for HTML 5 we are committed to XML and HTML serializations of the same DOM.
<noah> That's a significant constraint.
<caribou> yes
MS: as to the idea of using URIs associated with DOM Element items, I don't see any browser vendor support other than Microsoft, and [missed some]
NM: any fixed dates re this topic?
<raman> signing off. till next week, kudos to Liam for a useful meeting
DC: I don't see "distributed extensibility" in the list of deadlines http://dev.w3.org/html5/status/issue-status.html
PLH: [missed]
<caribou> does that impact webapps as well?
action-357?
<trackbot> ACTION-357 -- Henry S. Thompson to elaborate the DPD proposal to address comments from #xmlnames and tag f2f discussion of 2009-12-10, particularly wrt integration with XML specs and wrt motivation -- due 2010-01-12 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/357
NM: the extra-TAG participants here are welcome to join our continuing discussion
<plh> --> http://lists.w3.org/Archives/Public/public-html/2010Jan/0218.html Working Group Decision on ISSUE-76 Microdata/RDFa
PLH: note decision to separate Microdata out of HTML 5 spec
NM: note proposals are due January 16, 2010
LMM: the action [in the HTML WG?] was from Roy... asked for more time because it would involve lots of changes all over the document
<noah> Do we have a link to email from Roy? Wasn't to www-tag.
<masinter> http://lists.w3.org/Archives/Public/public-html/2010Jan/0208.html
<noah> From Roy's note:
<noah> It is nearly impossible to write a change proposal based on a
<noah> moving target to fix a pervasive misuse of terms in the
<noah> current draft. I could write the changes, but that would
<noah> effectively be forking HTML5 or replacing the current editor.
-> http://lists.w3.org/Archives/Public/public-html/2010Jan/0208.html request from Roy to extend deadline for change proposals
JAR: I see lots of traffic indexed under http://www.w3.org/html/wg/tracker/issues/81 ; anybody have a summary?
<masinter> my opinion on the topic was: http://lists.w3.org/Archives/Public/public-html/2009Oct/0184.html
<jar> ha.
<masinter> corrected by http://lists.w3.org/Archives/Public/public-html/2009Oct/0185.html
<noah> DC: Tim, have you read any of this. Oops.
<timbl> aaagh
<timbl> no i haven't read the email sorry
HT: in sum, I think we're agreed that this is deeply broken and ...
DanC: I'm not sure it's deeply broken
<noah> LM: I view this as editorial, not particularly serious
LMM: there are two concepts... it's a lot of editorial work to fix...
<masinter> there are two concepts that are different, and the same term is being used to refer to both of them
<Zakim> DanC, you wanted to fill tim in
<noah> DC: In the spec, URIs are used to refer to the bag of bits that come back.
<noah> LM: And also the resource at the end of the wire
<noah> TBL: The spec is somewhat (informal? scribe didn't get the exact word)
<noah> DC: CSS and XXX and YYY do this too.
<noah> TBL: People talk loosely about the resource being returned.
<noah> TBL: I think it's important to get the resource word used consistent with AWW; I'm less concerned about consistent use of representation. Alternatives to that might be OK.
<masinter> i vote to offer roy help if he wants it, but let him whack at it
<Zakim> htt, you wanted to agree with timbl and make a proposal
NM: I see Roy F. interested to do some work; I suppose we can stand by for that to happen... or...
HT: I agree that it's critical to distinguish aww:resource, i.e. that which a URI refers to, from that which comes back from a GET response.
<noah> Ooh, I don't like message.
HT: maybe message?
<noah> Too ambiguous with aspects of the response that are not the representation.
<Zakim> DanC, you wanted to note 'HTTP in RDF' spec possibly in last call
note http://www.w3.org/TR/2009/WD-HTTP-in-RDF10-20091029/
<noah> DC: There is a spec for HTTP vocabulary in RDF that may or may not be in last call, hard to tell. This came up in discussion of redirections and semweb arch. They have an RDF model for HTTP. One of the comments that I think Jonathan sent was "you're missing this thing called an entity"
<noah> DC: I'm not fond of that one, but...
<htt> HST thinks entity == message, in that you have to get to "entity body" before you get to == AWWW-representation
<noah> I suspect that the "pun" in HTML 5 spec is intentional, much as we may not like it. URI is a uniform RESOURC identifier --- poke one and you get back, guess what, a RESOURCE.
<noah> I know it's broken, but I'm not convinced they'll welcome a near synonym for representation.
<Zakim> DanC, you wanted to prefer that Message be used for a thing-in-time
<masinter> keep "message" as something that a sender sends to a receiver
<masinter> keep "representation" as something that results from interpreting a "message"
NM: the informality in the HTML 5 spec seems unfortunate, to me...
<masinter> to quote http://lists.w3.org/Archives/Public/public-html/2009Oct/0184.html : For a specification that goes out of its way, in other ways, to be careful to "match reality", this is a case where being following sloppy industry terminology leads to a failure to be consistent with the reality of what is actually implemented.
NM: seems more appropraite for tutorials, but I think they understand it but trying to hide it from their user community
<htt> NM's point reminds me that I have used "web page" for this purpose with comfort. . ,.
<Zakim> DanC, you wanted to note HTML WG sentiments on readership
<Zakim> jar, you wanted to say Ian denies the *existence* of awww:Resources
DC: one exercise is to do the
editorial work of finding terminology that appeals to a large
audience and how it impacts the spec...
... another is to find a critical bug that can't be fixed
without teasing apart representation [or message] vs
document/entity
... without time, perhaps you don't need to distinguish, but I
think there's stuff about caching in there, which certainly
involve time
<masinter> The main thing I thought was awkward was that the spec was unclear about situations where a URL (sic) had no representations, or when there were many (content negotiation)
TBL: yes, the rhetorical simplification of ignoring time is sometimes useful... perhaps more than we acknowledge [did I get that right?]
JAR: IIRC, this isn't just a choice of terms or confusions, Ian is saying that awww:resources don't exist; they're not worth talking about.
<htt> Tim, WebArch does talk about messages, e.g. "the message payload is the representation of this document."
<masinter> except for things that you POST to which don't have bags of bits?
<Zakim> htt, you wanted to suggest "web page"
JAR: what Ian says is observable is the servers and the messages. That's a principled stance.
<masinter> "message payload" seems fine: a message (some messages) carries a representation
<noah> Do you find that Web pages works for embedded images, CSS sheets, etc?
<noah> How about results of XMLHTTPReq requests?
HT: "web page" works, IME; e.g. "in the old days, web pages were files; but now they're computed..."
["web page" is compound more often than not these days]
HT is excused.
NM: next steps?
DanC: I'm content to see what happens
LMM: I think the TAG should say we're happy with the direction Roy's headed
DanC: yes, please
close action-358.
close action-358
<trackbot> ACTION-358 Schedule discussion of 'usage of 'resource' vs 'representation' in HTML 5, CSS, HTML 4, SVG, ...' [note follow-up discussion in www-archive] closed
<masinter> ok with me
<scribe> ACTION: Larry to tell the HTML WG the TAG encourages the direction Roy's headed on resource/representation and endorse his request for more time. [recorded in http://www.w3.org/2010/01/07-tagmem-minutes.html#action01]
<trackbot> Created ACTION-372 - Tell the HTML WG the TAG encourages the direction Roy's headed on resource/representation and endorse his request for more time. [on Larry Masinter - due 2010-01-14].
<masinter> sure it won't be more than 1 line
(which has a due date today?)
<noah> RESOLUTION: endorse the proposed disposition of HTML WG issue-59 in
<noah> http://lists.w3.org/Archives/Public/public-html/2009Dec/0249.html , i.e.
<noah> the class=author view and the informative reference guide, provided the
<noah> relaxng is appended to the informative reference guide, which will be
<noah> published as a Working Draft and taken to Last Call
(ah... 7 Jan date is in http://lists.w3.org/Archives/Public/www-tag/2009Dec/0087.html )
<noah> DC: we should wait for next draft
NM: so... are we ~happy?
<noah> I guess I took "take to Last Call" as shorthand for "put on the Rec track" (though not necessarily normative)
LMM: they could commit to publication; the chairs aren't inclined to put the question to the WG. I wonder if the issue should be closed.
"Those aren't exclusive; i.e. you can do a Last Call before a Note." -- DanC http://lists.w3.org/Archives/Public/www-tag/2010Jan/0006.html
<noah> Well, I think maintaining a document like this to the quality I'd hope is a serious commitment for a WG, and making a process-based commitment is one way to get it down unambiguously.
<noah> DC: I like Noah's idea of "we can't yet tell whether this is going to work for us, but some reason for optimism. Go head, and we'll reserve the right to raise issues again later."
<scribe> ACTION: Noah to convey, re language reference, to encourage the path they've indicated; we can't tell if we're satisifed; we'll stay tuned and comment when drafts become available [recorded in http://www.w3.org/2010/01/07-tagmem-minutes.html#action02]
<trackbot> Created ACTION-373 - Convey, re language reference, to encourage the path they've indicated; we can't tell if we're satisifed; we'll stay tuned and comment when drafts become available [on Noah Mendelsohn - due 2010-01-14].