Draft minutes from TAG Telcon 1st Nov 2007

Draft minutes from the TAG telcon on 1st Nov 2007 are available for review at:


and as plain text below.


Stuart Williams
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

                               - DRAFT -

                              TAG Weekly

1 Nov 2007


      [2] http://www.w3.org/2001/tag/2007/11/01-agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2007/11/01-tagmem-irc


          Raman, Stuart, Noah, DanC, Ht, DOrchard, TimBL

          Rhys, Norm




     * [4]Topics
         1. [5]Convene
         2. [6]TAG@TPAC November F2F
         3. [7]abbreviatedURIs-56 (ISSUE-56)
         4. [8]exi
         5. [9]TBL talk during tech plenary
     * [10]Summary of Action Items

   <scribe> scribenick: dorchard

   <scribe> scribe: dorchard


   APPROVED: minutes from 25th October

   Next telcon Nov 15th

   DanC will scribe

   resolved: next telcon Nov 15th

TAG@TPAC November F2F

   stuart: Meeting with HCLS IG in topic close to httpRange-14 and
   ... Current Plan is to meet 5pm-7pm Thursday 8th Nov.
   ... Current Plan is to meet 5pm-7pm Thursday 8th Nov.
   ... Possible option to switch to Monday (pm) or Tuesday (am).
   ... who will we lose if switch?

   <DanC> (what was plain text email?
   [11]http://www.w3.org/2001/tag/2007/11/05-agenda looks like
   hypertext to me. )

     [11] http://www.w3.org/2001/tag/2007/11/05-agenda

   stuart: may lose TimBL because he has confirmed thursday but not
   respons on m/t availability
   ... interested hcls members are boston local and can meet m/t
   ... if tbl can switch, I'll make the switch

   noah: my first choice is monday afternoon then after lunch on

   stuart: tuesday evening is AC meeting, no confict during day m/t


     [12] http://lists.w3.org/Archives/Public/www-html-editor/2007OctDec/0016

abbreviatedURIs-56 (ISSUE-56)

     [13] http://www.w3.org/2001/tag/group/track/issues/56

   <Zakim> DanC, you wanted to ask about status of comments on XHTML
   Role module (though not sure it fits neatly under abbreviatedURIs)

   I think our mechanisms for abbreviated URIs are insufficient

   raman: let's look at what people want
   ... html is saying no to ns.

   <Noah> DO: I'm on a tech. plenary panel looking at URI-based
   extensibility. The research that Ian Hickson has done for Google is
   fascinating. Looking at profile attributes and abbreviated names in
   HTML class attribute.

   <Noah> DO: The profile attribute is in some sense serving as a
   namespace-like mechanism governing the class attribute values.

   <Noah> DO: The reality is that nobody's doing it. As Ian found out,
   the profile attribute is used 90% less than one of the attributes in
   the class. What we've got simply isn't working. If we want URI-based
   extensibility, and if existing mechanisms aren't doing it in HTML,
   then we need to admit that.

   <Noah> DO: I believe in URI-based extensibility, but I also care
   about the reality of whether people are willing to actually use the
   mechanisms we're promoting.

   <Zakim> DanC, you wanted to disagree that little use means it's not
   working; we should only expect it to be used at the margin

   <Noah> DC: But way less than half the people need to extend HTML.

   <Noah> DO: I know.

   DC: I see lots of satisfaction in HTML
   ... now we now need the extension mechanisms
   ... it doesn't make sense to declare them a failure, because they
   haven't been needed until now
   ... if the problem is that humans can't handle URI based
   extensibility, then I'm going home....

   stuart: issue is xhtml role attribute and articulation of curies.
   ... appropriate that we look at this
   ... henry has brought us back to the question of do we need another
   URI syntax

   raman: I agree with much of Dan, extensions are happening on the
   ... extensions happen by the mechanisms of xml.
   ... xml based languages like svg, etc. use namespaces

   <DanC> (I heard TV say: the view that HTML extensions will happen
   via the XML mechanism, which defaults to namespaces; not everybody
   shared this view)

   raman: can't have 2 different mechanisms for extensions as they
   can't be combined in compound documents
   ... if you don't use namespaces for html, how do you bring xml
   languages in?

   <Zakim> Noah, you wanted to respond to Raman that I think the
   problems are deeper than XML-based vs. other means of extension

   <DanC> (I think we're talking more about TagSoupIntegration, but I
   think that always deserves pretty much top priority, so I don't mind

   noah: Henry took TBL's position that we don't need any more
   mechanisms than we already have
   ... then Dave said I'm not so sure that's true because the
   mechanisms aren't being used
   ... then raman said the schism is about xml vs non-xml based
   ... to what extent do members of html wg believe "rigorous"
   distributed extensibilty is important?
   ... answer is probably some do, some don't.
   ... may be that some believe that some names don't need URIs
   ... then next layer that says we do need them, and what technology
   is appropriate?
   ... then the next layer is the extensibility of html, whether it's
   xml like or not.
   ... and xhtml people have simpler answers than html given namespaces
   ... propose that we talk about first 2 points

   <Zakim> DanC, you wanted to say that my position on
   abbreviatedURIs-56 is that URI abbreviation is an issue specific to
   each host language; factoring CURIEs out of the RDFa spec doesn't

   stuart: this isn't about distributed extensibility, this is about

   noah: dave's point is that curies are about distributed

   danc: each host language will have specific issues around
   abbreviated URIs

   stuart: 3 articulations of abbreviated URIs...

   <DanC> ("all three are in the agenda"? I see "Both documents ")

   stuart: hearing that there is no tag opinion on this

   dorchard: I've had new information so I'm rethinking my position on
   abbreviated URIs

   danc: I don't subscribe to factor out curies.

   <DanC> 3.1.1. CURIE Syntax Definition

     [14] http://www.w3.org/TR/2007/WD-xhtml-role-20071004/#sec_3.1.1.

   <DanC> (hunting for an example of []s... I don't see one)

   timbl: there are a lot different issues in there

   <ht> DanC, look at the first production of the syntax

   <DanC> the production has an example?

   <Stuart> DanC, it's also at

     [15] http://www.w3.org/MarkUp/2007/ED-curie-20070905/#s_syntax

   timbl: at one point there was an ambiguity between URI scheme vs
   namespace prefix.

   <DanC> I don't look at editor's drafts outside the group I'm in

   <DanC> if they want review from outside the WG, they should publish
   on [16]http://www.w3.org/TR/

     [16] http://www.w3.org/TR/

   timbl: can you put these in href?

   noah: skimming the spec, the spec is ambiguous because it does
   things by example.

   timbl: a relative reference is not a qname afterwards, it's a
   relative URI
   ... the thing they call a reference is not a qname because it can
   have "/" in it.

   stuart: it's a way of abbreviating a URI

   danc: one of the problems before was names couldn't start with a
   digit, this is now much than solving that problem

   timbl: seems powerful and useful to arbitrarily break URIs

   noah: tbl raises the point about in hrefs or not,

   <Stuart> irelative-ref = irelative-part [ "?" iquery ] [ "#"
   ifragment ]

   <Stuart> irelative-part = "//" iauthority ipath-abempty

   <Stuart> / ipath-absolute

   noah: I'd be more comfortable if it said things like "the use of
   things must not be allowed where you also allow URIs".
   ... they don't say there's an architectural principle that you could
   confuse the colon with a URI scheme separator.
   ... they ought to at least clarify this.
   ... this is like a union that says numbers or "unbounded"

   raman: similar to attribute value templates

   <Stuart> Ooops:page break in the RFC:

   <Stuart> irelative-part = "//" iauthority ipath-abempty

   <Stuart> / ipath-absolute

   <Stuart> / ipath-noscheme

   <Stuart> / ipath-empty

   raman: if you see these brackets then do some processing

   <DanC> (attribute value templates in XSLT are not the happiest
   thing... when writing XSLT, I spend half my time debugging "$foo" vs
   "{$foo}" )

   noah: one way to resolve ambiguity is to take a character not in
   URIs, like curly brackets, and trigger off that.

   <timbl> In [17]http://www.ietf.org/rfc/rfc3987.txt , irelative-ref
   is defined aparentluy to alway start wt "/"

     [17] http://www.ietf.org/rfc/rfc3987.txt

   noah: another way is to use different attributes based on the type
   ... many ways to skin the cat and avoid the ambiguity

   <timbl> [18]http://www.w3.org/1999/xhtml/vocab#cite

     [18] http://www.w3.org/1999/xhtml/vocab#cite

   <timbl> http is te namespace

   <timbl> irelative-ref = irelative-part [ "?" iquery ] [ "#"
   ifragment ]

   <timbl> irelative-part = "//" iauthority ipath-abempty

   <timbl> / ipath-absolute

   <Stuart> timbl, I think those '/'s are alternates

   <DanC> (tim, are you exploring perverse design spaces for the fun of
   it? I wonder where you're going.)

   <timbl> ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]

   noah: thinking about xml:base URIs
   ... kind of a precedent there.
   ... at least a document establishes a base uri

   <DanC> (yes, it seems like CURIES are more about named base URIs
   than QNames)

   <Zakim> DanC, you wanted to say using anything qname-like in the
   href attribute is a non-starter, but I thought the RDFa designers
   had accepted that. and to point out 3 year old comment

   noah: an attribute like xml:base overrides the base uri, and how is
   this any different?

   danc: URI abbreviation thing is language is specific

   <timbl> I note that the rule "f the prefix is omitted from a CURIE,
   the default value of [19]http://www.w3.org/1999/xhtml/vocab# MUST be
   used." is different from "f the prefix is omitted from a CURIE, the
   default value of "#" must be used to reference the local document.

     [19] http://www.w3.org/1999/xhtml/vocab

   danc: if you stick x:y in an href, the deployed software will treat
   x: as a scheme.
   ... and if you put [] around it's treated differently
   ... I made the comment that [] in an href is a nonstarter
   ... because it's treated as a URI
   ... my comment showed that [abc:def] then it'll get parsed as a
   relative reference, specifically a file name

   <Noah> So, if base URI is [20]http://example.org/mydoc.html

     [20] http://example.org/mydoc.html

   danc: the TAG is not doing html design
   ... my position is don't factor out CURIES.

   <Noah> If href="[abc:xyz]", are you saying that resolves to

     [21] http://example.org/mydoc.htmlabc:zyz?

   <Noah> or

   <Noah> If href="[abc:xyz]", are you saying that resolves to

     [22] http://example.org/mydoc.html#abc:zyz?

   <Noah> or

   <Noah> If href="[abc:xyz]", are you saying that resolves to

     [23] http://example.org/mydoc.html/abc:zyz?

   danc: each of these syntaxes are slightly different

   timbl: thing on the right is numbers, letters, hyphens, etc.
   ... thing on the left is different

   <DanC> "allmost all the time"? I'd need measurements before I'd
   believe that.

   timbl: most of this is targetted at people using latin text using
   ... we could search but we'll find very cases where qnames start
   with [
   ... this issue isn't deployed software, it's deployed documents
   ... the damage to humanity of using [] vs something else
   ... the # of times that [ is used

   danc: and you have to factor in all the silent failures in current

   <DanC> (but now we're doing HTML syntax design. again.)

   timbl: that is much bigger, if you are going to use this in href..

   danc: does anybody know whether this was supposed to go into href?

   <Noah> From their syntax section: "To disambiguate a CURIE when it
   appears in a context where a normal [URI] may also be used, the
   entire CURIE is permitted to be enclosed in brackets ([, ])."

   noah: yes it is a goal to be used where URIs are expected but
   doesn't answer href question?

   <DanC> my years-old comment:
   st=public-rdf-in-xhtml-tf 27 Oct 2005 curie compatibility, scope,

     [24] http://www.w3.org/2002/02/mid/1130467452.27261.683.camel@dirk;list=public-rdf-in-xhtml-tf

   <timbl> Abstract

   <timbl> The XHTML Role Attribute defined in this specification
   allows the author to annotate XML Languages with machine-extractable
   semantic information about the purpose of an element.


     [25] http://www.w3.org/TR/2007/WD-xhtml-role-20071004/#sec_3.1.1

   stuart: part of our confusion is which piece of text we should be
   looking at

   danc: they said they are in LC..

   stuart: their document says "Note that .. will be defined in an
   external document"

   <Stuart> 3.1.1. CURIE Syntax Definition

   <Stuart> Note that this syntax definition will ultimately be defined
   in an external document [CURIE].

   noah: going to LC and leaving to later the big architectural issue
   of curies

   <Stuart> ack

   <Noah> DO: One TAG approach would be to say "don't exit LC on the
   role attribute until the more general syntax document has moved
   forward status-wise". I could live with that.

   <Noah> I think that's architecturally appropriate, because that's
   where we'll have the debate about using these where URI's can go in
   general, etc. (Noah)

   stuart: external document is a product of an external group
   comprised of html and rdfa.

   noah: can live with where dave is signalling

   <Noah> I said that I think the architectural connection or
   dependence is there. I also said that I'd like to see RDFa move
   forward promply and I don't want to be unduly disruptive to them,
   but at least in principle I think the role attribute should wait for
   the general CURIEs issues to be worked out.

   <DanC> (if they want to factor out the CURIE spec, they should
   announce a charter change to call for participation from URI syntax
   experts )

   timbl: rdfa is in first public WD

   <Noah> Where I said above RDFa, I should have said XHMTL Role
   attribute. That's the one trying to go last call.

   noah: what's our level of confidence?
   ... i'm thinking of how where curies can be used wrt URIs and with
   what syntax
   ... and how are we constrained by what xhtml role done

   danc: I haven't seen any plan around xhtml2 that I'm comfortable

   <ht_home> except my phone isn't ringing :-(

   stuart: won't this come up in a transition?

   danc: only if there's an objection?

   noah: aren't we discussing whether we should make an objection?

   I propose that the TAG object to xhtml role progressing because the
   curie spec isn't far enough along and we don't know whether there
   will be problems or not?

   <DanC> (what SKW just said is the substance of my Oct 2005 comment
   ct/0071.html ; if the TAG wants to endorse that, fine by me)

     [26] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Oct/0071.html

   raman: I don't agree, the TAG shouldn't just push back on schedule

   noah: they probably can push back and say the tag hasn't raised a
   technical concern, please come back with a technical concern.

   raman: we should let them run and fall off a cliff.

   stuart: do we have a comment?
   ... dave made a proposal

   raman: I oppose dave's comment.

   stuart: how about Dan's comment?

   danc: we could ask about use in href?

   <DanC> asking about how CURIEs relate to html @href sounds good to

   raman: I could support asking about html href

   <Stuart> So a comment question of "Please explain your intentions
   wrt to the use of CURIEs in conjunction with html@href."

   ( I missed henry's comment)

   ht: let the TAG suggest full use of URIs within role attribute.

   timbl: we need damage report of compatibility.

   ht: I think there is a problem with use of [ in the host portion of
   ... so they can put an arbitrary hex string in ipv6

   <DanC> (I think the ITPC/Misha ship has sailed, though I wouldn't
   mind if somebody wants to find out for sure)

   <scribe> ACTION: ht to check into [ in ipv6 and hence host names
   [recorded in

     [27] http://www.w3.org/2001/tag/2007/01-minutes#action01

   <trackbot-ng> Created ACTION-69 - Check into [ in ipv6 and hence
   host names [on Henry S. Thompson - due 2007-11-08].

   stuart: I can send a message from the TAG asking about href

   <Stuart> So a comment question of "Please explain your intentions
   wrt to the use of CURIEs in conjunction with html@href."

   <DanC> RESOLVED to endorse that comment Stuart scribbled

   <scribe> ACTION: Stuart to send a comment to xhtml folks of Please
   explain your intentions wrt to the use of CURIEs in conjunction with
   html@href [recorded in

     [28] http://www.w3.org/2001/tag/2007/01-minutes#action02

   <trackbot-ng> Created ACTION-70 - Send a comment to xhtml folks of
   Please explain your intentions wrt to the use of CURIEs in
   conjunction with html@href [on Stuart Williams - due 2007-11-08].

   <DanC> (back to [29]http://www.w3.org/2001/tag/2007/11/05-agenda )

     [29] http://www.w3.org/2001/tag/2007/11/05-agenda

   <DanC> HCLSIG/TAG 1p-2p Tue 6 Nov, tentative


   ht: would like to get clearer what our perspective is?
   ... basically, what is the right analogy for exi in existing web
   ... I think the answer is surprisingly that web arch doesn't have
   much to say
   ... 1) like using a very obscure character encoding

   <DanC> 2) SVGz

   2) like an obscure content encoding like svgz which never claims to
   be xml

   <DanC> 2) content encoding, e.g. SVGz

   <DanC> (SVGz never claims to be XML? I didn't hear him say that, and
   I don't think it's true)

   scribe: 3) like a java serialization, because it doesn't map
   character to characters

   <Noah> I think the key point of Web architecture is: "Thus, before
   inventing a new data format (or "meta" format such as XML),
   designers should carefully consider re-using one that is already

   <Noah> That's from the start of the Web Arch section on Data

   stuart: will move this to the f2f.

TBL talk during tech plenary

   tbl: what are some issues for each domain and "cracks in the
   ... are these good cracks or bad cracks, that is allow for
   innovation vs weakening the foundation
   ... if I could talk about 5 of these things, which 5 would it be?
   ... 1) instructions to ignore mime type
   ... 2) embedding of videos in svg, redone in html
   ... 3) tag soup

   <DanC> (and HTML and SVG video are both playing catch-up w.r.t.
   flash video)

   henry: chasing the html5 folks that they picked the wrong end of
   Postel's law

   <DanC> (I'm too far behind on my own TPAC talk prep to think about
   timbls ;-)

   henry: html5 folks are standardizing what they accept
   ... postel's law is standardizing on what you produce

   danc: tragedy of commons may be applied to internet or web
   ... used to put out things for community review and mega scale
   before giga scale
   ... for example role="nofollow"

   <DanC> (if there was _any_ open review of nofollow prior to
   deployment, it's news to me)

   raman: it's a different way of getting community review
   ... similar to the way english is evolved

   <Noah> scribenick: Noah

   DC: Henry got into Postel's law. What did that relate to?

   HT: Tag soup.

   SW: You referenced tragedy of the commons.

   HT: Following on Raman's point, it would be good to look for things
   that got deployed at giga-scale and then didn't get traction or work
   out well.

   TBL: Such as?

   <timbl> -od we review things first?

   HT: Not thinking of it fast.

   <timbl> iTunes protocol?

   TVR: itunes protocol (scheme) is only used in the one context.
   ... rel="nofollow" is something you don't do if it doesn't work for

   DC: Some concern with it being a verb.
   ... The market often works, but there used to be a value also of
   submitting for community review, and during my career that seems to
   have largely disappeared.

   TVR: In W3C, we say we do Recommendations not standards.

   DC: We now say we are accountable to the whole community. Was a big
   change that we'd consider Last Call from everyone.

   NM: Sometimes people are skipping the reviews for speed, but with
   good intentions. Sometimes the situation is that people are pushing
   things without believing they are in the community's larger

   DC: We need to assume a degree of mutual distrust in any system
   that's going to work.

   TBL: Well, we can also try to establish the incentives to finding
   mutual trust.

   <DanC> (I'm reminded of the internet driver's license idea... but
   yes, better certs are worth doing.)

   TBL: Supposing we said we're going to make a particular sort of
   browser that's authenticated, but banks would use it. Wouldn't let
   Javascript run.

   TVR: WIll market economics get you there?

   <DanC> (it's a race to the bottom... there's lots of money to be
   made by taking _more_ risk, using _less_ security stuff. and the
   bottom is below zero; it's the mafia folks running zombie armies.)

   NM: Standards win when you can show them that they win by doing
   things the >same< way. Nobody breaks TCP/IP, because they want
   TCP/IP to work.

   TBL: Maybe true, but not helping me with my talk.

   <DanC> (not sending engineers to maintenance mode WGs? hmm... XML
   Core is a testament to the contrary; is it just that Paul Grosso is
   a saint?)

   TBL: I'm looking for cracks in the architecture.

   HT: Nobody's sending people to the workgroups to do maintenance.

   NM: That's an organizational crack, not an architectural crack.

   TVR: People aren't waiting for the standards process to evolve
   things like HTTP. The distributed extensibility of XML etc. may be
   promoting this. They consider the work to be done on the core stds.
   ... Is that a crack in the architecture?

   <DanC> (I think flash fills real needs for short-term stuff, but due
   the rule of least power, declarative stuff like HTML will continue
   to win out for meat-and-potatoes info exchange.)

   NM: We see things like Flash and Silverlight. Is it a "crack in the
   architecture" that we don't have a Recommentation or RFC-level stack
   that everyone's ready to widely deploy and jump on to make sure that
   typical content on the Web remains non-proprietary (I say that
   without meaning to comment on the merits of Flash or Silverlight per

   TVR: Extensibility and TAG Soup?

   SW: Tim, got what you need?

   TBL: Maybe need 6 have, 2.

   TVR: Media type issue - I.e. authoritative metadata.

   SW: Can we do Monday afternoon instead of Tues? We'd get to keep the
   ... OK, I'm going to aim for Monday afternoon.
   ... Adjourned.

   <DanC> (the padlock is the WSC WG; passwords in the clear is the TAG
   issue; they're not the same)

   HT: Two thoughts-- 1) cleaning up the padlock and 2) peer to peer

   DC: We have chartered a WG to tackle the padlock problem. That's the
   Web Security Context WG. Watch for unintentionally undercutting

   TBL: Right. These are just things people think are important.

   TVR: Right. There's a WG for Tag Soup too.

Summary of Action Items

   [NEW] ACTION: ht to check into [ in ipv6 and hence host names
   [recorded in
   [NEW] ACTION: Stuart to send a comment to xhtml folks of Please
   explain your intentions wrt to the use of CURIEs in conjunction with
   html@href [recorded in

     [30] http://www.w3.org/2001/tag/2007/01-minutes#action01
     [31] http://www.w3.org/2001/tag/2007/01-minutes#action02

   [End of minutes]

    Minutes formatted by David Booth's [32]scribe.perl version 1.128
    ([33]CVS log)
    $Date: 2007/11/12 11:52:06 $

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

Received on Monday, 12 November 2007 12:06:46 UTC