minutes TAG weekly 7 Jan for review


              Technical Architecture Group Teleconference
07 Jan 2010
      [2] http://lists.w3.org/Archives/Public/www-tag/2010Jan/0017.html
   See also: [3]IRC log
      [3] http://www.w3.org/2010/01/07-tagmem-irc

          Masinter, jar, DanC, noah, Raman, Ashok_Malhotra, Liam, Plh,
          Carine, John_Kemp, Mike, Ht, Timbl
          noah, DanC


     * [4]Topics
         1. [5]Convene
         2. [6]ACTION-356: Name qualification mechanisms for HTML 5
            (xmlnames) (ISSUE-54)
         3. [7]HTML 5 and Microdata
         4. [8]ACTION-358: Usage of "Resource vs. Representation" in
            HTML 5
         5. [9]HTML 5 Language Reference / Authoring Specification
     * [10]Summary of Action Items

   <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

     [11] 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

     [12] 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

     [13] http://www.w3.org/2010/Talks/01-07-liam-namespaces/

ACTION-356: Name qualification mechanisms for HTML 5 (xmlnames)

   <DanC> [14]Unobtrusive Namespaces (slides)

     [14] http://www.w3.org/2010/Talks/01-07-liam-namespaces/

   <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

   <DanC> LQ: yes, there two proposals, one "unobtrusive" and another

   <noah> Welcome, Tim. We're on

     [15] 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> [16]http://www.w3.org/2001/tag/group/track/actions/357

     [16] 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

     [17] 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

   <Liam> (URLs are on slide 5)

   <inserted> scribenick: noah

   DC: The proposals are cited on slide 4 or 5, I think.

   <masinter> see

     [18] 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

   <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

   <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

   <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

   LQ: there's been a long-standing demand in the XML community for
   mixing and mashing namespaces

   <noah> James Clark blog posting:

     [19] 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

   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


     [20] 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

   <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> [21]http://blog.jclark.com/2010/01/xml-namespaces.html

     [21] 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:

   <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

   DC: I don't see "distributed extensibility" in the list of deadlines

     [22] http://dev.w3.org/html5/status/issue-status.html

   PLH: [missed]

   <caribou> does that impact webapps as well?


   <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> [23]http://www.w3.org/2001/tag/group/track/actions/357

     [23] http://www.w3.org/2001/tag/group/track/actions/357

   NM: the extra-TAG participants here are welcome to join our
   continuing discussion

HTML 5 and Microdata

   <plh> -->
   l Working Group Decision on ISSUE-76 Microdata/RDFa

     [24] http://lists.w3.org/Archives/Public/public-html/2010Jan/0218.html

   PLH: note decision to separate Microdata out of HTML 5 spec

ACTION-358: Usage of "Resource vs. Representation" in HTML 5

   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.


     [25] 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.

   l request from Roy to extend deadline for change proposals

     [26] http://lists.w3.org/Archives/Public/public-html/2010Jan/0208.html

   JAR: I see lots of traffic indexed under
   [27]http://www.w3.org/html/wg/tracker/issues/81 ; anybody have a

     [27] http://www.w3.org/html/wg/tracker/issues/81

   <masinter> my opinion on the topic was:

     [28] http://lists.w3.org/Archives/Public/public-html/2009Oct/0184.html

   <jar> ha.

   <masinter> corrected by

     [29] 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

   <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

   <noah> Ooh, I don't like message.

   HT: maybe message?

   <noah> Too ambiguous with aspects of the response that are not the

   <Zakim> DanC, you wanted to note 'HTTP in RDF' spec possibly in last

   note [30]http://www.w3.org/TR/2009/WD-HTTP-in-RDF10-20091029/

     [30] 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

   <masinter> keep "message" as something that a sender sends to a

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

     [31] http://lists.w3.org/Archives/Public/public-html/2009Oct/0184.html

   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

   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

   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

   <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

   DanC: yes, please

   close action-358.
   . ACTION Larry: tell the HTML WG the TAG encourages the direction
   Roy's headed ...

   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
   . ACTION Larry: tell the HTML WG the TAG encourages the direction
   Roy's headed and endorse his request for more time.
   . ACTION Larry: tell the HTML WG the TAG encourages the direction
   Roy's headed on resource/representation and endorse his request for
   more time.

   <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

     [32] 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

HTML 5 Language Reference / Authoring Specification

   (which has a due date today?)

   <noah> RESOLUTION: endorse the proposed disposition of HTML WG
   issue-59 in

   l , i.e.

     [33] http://lists.w3.org/Archives/Public/public-html/2009Dec/0249.html

   <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
   [34]http://lists.w3.org/Archives/Public/www-tag/2009Dec/0087.html )

     [34] 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

     [35] 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."
   .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

   <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

     [36] 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].

Summary of Action Items

   [NEW] 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
   [NEW] 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

     [37] http://www.w3.org/2010/01/07-tagmem-minutes.html#action01
     [38] http://www.w3.org/2010/01/07-tagmem-minutes.html#action02

   [End of minutes]

    Minutes formatted by David Booth's [39]scribe.perl version 1.135
    ([40]CVS log)
    $Date: 2010/01/07 19:41:15 $

     [39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [40] http://dev.w3.org/cvsweb/2002/scribe/

Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Thursday, 7 January 2010 19:46:19 UTC