See also: IRC log
<scribe> scribenick: dorchard
<scribe> scribe: dorchard
APPROVED: minutes from 25th October
Next telcon Nov 15th
DanC will scribe
resolved: next telcon Nov 15th
stuart: Meeting with HCLS IG in topic close to httpRange-14 and friends.
... 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? http://www.w3.org/2001/tag/2007/11/05-agenda looks like hypertext to me. )
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 tuesday
stuart: tuesday evening is AC meeting, no confict during day m/t
<Stuart> http://lists.w3.org/Archives/Public/www-html-editor/2007OctDec/0016
<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 margins
... 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 extensibility
... 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 curis
noah: dave's point is that curies are about distributed extensibility
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 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 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 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 http://www.ietf.org/rfc/rfc3987.txt , irelative-ref is defined aparentluy to alway start wt "/"
noah: another way is to use different attributes based on the type
... many ways to skin the cat and avoid the ambiguity
<timbl> 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 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.
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 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 http://example.org/mydoc.htmlabc:zyz?
<Noah> or
<Noah> If href="[abc:xyz]", are you saying that resolves to http://example.org/mydoc.html#abc:zyz?
<Noah> or
<Noah> If href="[abc:xyz]", are you saying that resolves to 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 colons
... 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 software.
<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: http://www.w3.org/2002/02/mid/1130467452.27261.683.camel@dirk;list=public-rdf-in-xhtml-tf 27 Oct 2005 curie compatibility, scope, timeline
<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.
<timbl> 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 with
<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 http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Oct/0071.html ; if the TAG wants to endorse that, fine by me)
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 me
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 ipv6
... 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 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 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 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 architecture?
... 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
ht: 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)
ht: 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 available."
<Noah> That's from the start of the Web Arch section on Data Formats.
stuart: will move this to the f2f.
tbl: what are some issues for each domain and "cracks in the architecture"
... 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 you.
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 interest.
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 se)
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 room.
... 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 them.
TBL: Right. These are just things people think are important.
TVR: Right. There's a WG for Tag Soup too.