See also: IRC log
<DanC> minutes 9 July
RESOLUTION: Minutes of 9 July 2007 at http://www.w3.org/2001/tag/2007/07/09-tagmem-minutes are approved
SW: Next proposed telcon is 13 Aug. Norm will chair.
... Proposed scribe is Dave, who is not available today to confirm. Norm will be responsible for confirming/recruiting scribe.
... Moving on to actions assigned to Norm. Scribe will make separate topics for some of these...
SW: The agenda lists several issues to be completed/withdrawn/continued without discussion. Any discussion?
Silence.
RESOLUTION: Norm's actions listed in http://www.w3.org/2001/tag/2007/07/16-agenda to be continued/withdrawn/continued without discussion are indeed disposed of accordingly.
SW: Tim and Olivier Thereaux exchanged emails
<Stuart> http://lists.w3.org/Archives/Public/www-tag/2007Apr/0084
See: http://lists.w3.org/Archives/Public/www-tag/2007Jun/0115 and http://lists.w3.org/Archives/Public/www-tag/2007Jun/0118
TBL: The TAG might be in a position to take a role in the drivers seat here.
... Consider the role of the validators.
... People convey information in microformats, to some degree overloading the use of the class attribute.
<DanC> e.g. http://www.w3.org/TR/2007/WD-aria-role-20070601/
<DanC> relevant WG seems to be http://www.w3.org/WAI/PF/
<timbl> wai aria
<DanC> e.g. role="wairole:checkboxtristate"
<timbl> class="foo axs slider whatever"
TBL: They are using the class attribute to convey something about the role, from an accessibility perspective, of certain of the HTML bits.
... class is now more clearly moving to being a space-separated list
... axs is "magic", in that the meaning of everything following it in the list is changed.
... Issues in doing this include that class is not in fact an ordered list.
... Furthermore this approach doesn't scale, because only one specification can grab the semantics of the end of the list. What if someone else wanted to play the same game? So, why not use XML and element structures? The concern seems in part to be the validator. HTML specification allows it, but the validator complains.
... We in W3C control this, and it would be good for us to get it fixed.
<Zakim> DanC, you wanted to note that validators are relevant, but to note that HTML extensibility is the crux of the issue
DC: Tim seems to have the balance about right on talking about the significance of the validator in this. Interestingly, what they're doing in the implementation, is to rummage around using Javascript, find the axs in the class=, then edit the DOM to add a role= attribute after all!
TBL: I'd be willing to look for resources to support doing the work.
SW: What are you asking of the TAG?
TBL: 1) agree 2) provide some moral support, in saying that the TAG agrees this to be an important use of W3C resources. That makes it easier for me to make the case when actually justifying the resources. I feel that when you give the validator a URI, you are asking it to test against Web architecture.
SW: Could be quite a lot of work.
TBL: Some of the problems come from being DTD-based.
DC: Careful, DTD's are important to many users.
TBL: Yes, but we need it to be more incremental.
<Zakim> Noah, you wanted to ask whether the incrementality would be confusing, if not done with great care.
TBL: Having tags that don't nest as a tree is just plain bad, and should be reported as such. Many other issues, such as use of unknown tags, are not necessarily errors. Give people a report ordered by priority.
NM: Yes, I agree. The incrementality of the report is important, BUT it's also important to design a UI that will give good guidance to those who are looking for a clear, novice's reading on whether their HTML is OK. Unfortunately, what one user wants won't always be the same as what other users want (did you mean to use extensions?), so the UI should be designed with some care.
SW: Tim, are you OK taking the lead in promoting this?
TBL: Well, I'm comfortable at least talking to the AC and blogging. Going beyond that, e.g. to external sources, is less clear.
DC: Is this really a money problem? We have lots of people already working in the area, e.g. in the HTML working group.
... Also, Olivier's role in this is important.
TBL: Yes, but he's very open to comment and input.
DC: We as the TAG can also help them take the heat if users complain about the changes.
TBL: I think he's got a framework for a new implementation.
<DanC> Unicord
DC: Yes, I think so, though Tim's earlier statement that it's Python-based doesn't seem right to me.
<DanC> Unicorn
SW: Is there a statement that TAG could make that would be helpful?
<DanC> Meet the Unicorn, Q&A Weblog [was QA weblog]
TBL: The architectural statement to be made would be that: "Extensibility of HTML using XML, I.e. with new elements and attributes is good practice, and it's important for the validators to facilitate such practice."
<DanC> that was from July 5, 2006; I think a release is upcoming or recent
DC: One issue has been the tradition that the validator only deals explicitly with things that have reached Recommendation status.
TBL: Could be changed to flag in yellow "we are happy that you are experimenting with technology that's coming through the wg's, but do note that what you're doing is not yet covered by a Recommendation"
SW: Is the action to have a conversation with Olivier?
TBL: And then possibility write something?
SW: Yes. Goal with Olivier would be to get his help in drafting a position that we as the TAG could promote, and that he would find helpful.
DC: Direction sounds right. Timeframes need to be short. Needs attention every few weeks. It shouldn't be the start of a monolithic effort with a 3 year horizon.
TBL: yes.
DC: Three year project with releases every 4 weeks is good.
SW: I'm disappearing soon. I could start the converation, but...
TBL: Dan and I could drive this. Anyone else particularly interested?
DC: Norm and TV.
NM: I'll help if needed, but others have more subject matter expertise. Ask if you need me.
SW: Action will be to work with Olivier to draft a position for consideration by the TAG
<DanC> this is about extensible languages at least as much as the validator
ACTION: Dan to work with Olivier and Tim to draft a position regarding extensibility of HTML and the role of the validator for consideration by the TAG [recorded in http://www.w3.org/2007/07/16-tagmem-irc]
<trackbot-ng> Created ACTION-7 - Work with Olivier and Tim to draft a position regarding extensibility of HTML and the role of the validator for consideration by the TAG [on Dan Connolly - due 2007-07-23].
<DanC> (do we use trackbot? do I need to take issue with " due 2007-07-23")
DC: I just sent email (see http://lists.w3.org/Archives/Public/www-tag/2007Jul/0048.html ).
... We claim that people can name things what they want, but in fact if you name your Web resource something ending in robots.txt, implementations break. Similarly, if you just happen to choose an HTML class attribute value "vcard", you may break things.
... I note that the profile attribute used by GRDDL is now gone. I've asked for it to be put back.
(Scribe is only hearing evey other word of what Dan is saying...)
NM: I think we're hitting the usual tradeoff. There are architecturally robust schemes for inventing non-colliding names. They support distributed invention in much more robust ways, but are perceived as inconvenient. Some appear to believe that the need for distributed extensibility is not so import. Round we go. What's new?
DC: What's new is that GRDDL just went through adding up its external dependencies, had to figure out HTML 5, and got worried about the profile attribute.
SW: If this were a W3C spec, we'd agonize in certain known ways about the disappearance of such an attribute.
DC: Well, HTML 5 is now in a W3C WG.
SW: Is there a concern on the behalf of the WG chair about a decision made by the WG?
DC: No decision was made. I'm discussing the state of the latest editors' draft. Latency in interacting with the editors seems to be in the range of several months, at least for some issues. I haven't pushed this one hard.
SW: Is there something the TAG could do that would be helpful?
DC: Don't think so. I'm pointing you to the IRC discussion. There is often a focus on looking at whether features are used in non-trivial numbers of pages, and if so whether they're used right. Hard to argue with that. Then again, accessibility can be a counterargument. Sometimes it's important that something that's rarely used be there.
SW: Is there a way of using GRDDL with HTML 5?
DC: Yes and no. No, in that the GRDDL spec talks explicitly about XML. Yes, in that GRDDL implementations in practice tend to use TAG soup parsers that accept HTML 5, profile attrs, etc.
TBL: This is importantly about interoperation. It's important that two people encountering the same document and "following their noses" come to the same conclusions about what it means.
NM: I would be happer if the documentation for the class attribute said "warning, while it appears that most values of this attribute are available for general use, this is subject to change. Strings like vcard may retroactively be given special meaning, and if that happens, you may have to change documents that used it for other reasons." That would be an honest spec., correctly warning of how it's being used.
DC: The "consent of the governed" is important. The marketplace has spoken, they like simple. Maybe we should write a finding that says that.
NM: The marketplace has spoken both ways. Yes, we see mainly simple, overloadable values for class attributes. It would be wrong, though, to say that nobody ever takes the trouble to fully namespace qualify things. That usage is widespread too.
DC: The one that really bothers me is rel="nofollow". We've been reluctant in the past when big players try to force de-facto standardization. Why is this more appealing? Just because it's to fight spam?
SW: Is there more we should do or say?
DC: I think I've said what I have to say in the 0571 email cited above. We could just stand by for awhile.
SW: I don't see an obvious action for us at the moment.
(Chair begins a digression...)
SW: I have been somewhat delinquent in setting up the TAG blog
(We now return to our regularly scheduled programming...)
SW: I am a bit reluctant to move on, since we didn't reach useful conclusion here. Nonetheless...
From the agenda:
Two expressed concerns
* 303 response cacheability and additional round trips.
* Address bar and book marking confusion
<DanC> (I notice tracker hasn't picked up my msg on standardizedFieldValues-51 http://www.w3.org/2001/tag/group/track/issues/51 ; it's critically unfit until it can do that.)
TBL: Recall we suggested that the TAG suggested used of 303 redirects for response to GET for non-information resource with no # in URI. Turns out the HTTP specification prohibits caching of 303 responses. No idea why.
SW: Roy Fielding has spoken up to say that this is just a bug in HTTP that should be fixed. Responses should be cacheable. See http://lists.w3.org/Archives/Public/www-tag/2007Jul/0035 and http://lists.w3.org/Archives/Public/www-tag/2007Jul/0047 .
TBL: OK, so declaring it a bug in HTTP and fixing is one approach. Another would be to invent a new code, perhaps a 203 (as suggested to me by someone). Problem arises if many things redirect to the same resource.
SW: What would 203 signify?
TBL: Equivalent to 303 followed by 200. "I would have redirected you to URI2 using status code 303, and had you done a GET to that, here's what you would have gotten." Saves the round trip.
<Zakim> DanC, you wanted to suggest test cases to back "that's a bug" position
DC: Roy's "that's a bug" position is pertinent historically, but what software does matters too.
TBL: Squid doesn't cache it.
DC: Does it matter what squid does?
TBL: If we agree with Roy that it's a bug, then we would put it on an errata list for the HTTP spec...
DC: That's not what I'm asking: what is the use case?
>> Norm Walsh joins the call
TBL: If tabulator does a FOAF lookup when online it gets a 303. If offline with squid installed, it doesn't work, because caching doesn't happen.
DC: Test it with cache control, please.
TBL: Gee, getting the 303 done wasn't easy.
DC: But you did, so doesn't that make it easier to try this experiment? Test cases are the way to get problems solved.
<DanC> "Cache-control can be used to override it." -- http://lists.w3.org/Archives/Public/www-tag/2007Jul/0035.html
TBL: Suppose someone tests with squid, and squid doesn't obey the cache control, then squid is wrong.
NM: My reading of Roy's note is different. I read him to say: "the HTTP specification currently (and erroneously) prohibits caching of 303 responses." The discussion of using cache-control is in text he proposes as a fix.
Msg 0047 from Roy claims the current text is: "The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable."
NM: It seems Squid would be doing the right thing per that spec to not cache the fact that a 303 had happened, or the URI that came back with the 303.
Roy then says "I would change the entire section to:"
(quoting just the part on caching)
"A 303 response SHOULD NOT be cached unless it is indicated as cacheable by Cache-Control or Expires header fields. Except for responses to a HEAD request, the entity of a 303 response SHOULD contain a short hypertext note with a hyperlink to the Location URI."
SW: Who is looking at 2616 wrt/ update and errata?
<Stuart> http://lists.w3.org/Archives/Public/www-tag/2007Jul/0046
SW: Still a question of what implementations are doing, and whether they would view this as bug or feature?
... Tim, what about the bookmarking issue?
TBL: That's a separate question. I don't think you can hope to have a conventional browser understand the bookmarking of a page vs. the object discussed by the page unless you change the browsers. Tabulator is an example of a Firefox extension that provides some of that capability.
SW: Tim, you seemed to be asking to have an issue. What about doing it under httpRange-14?
TBL: Prefer not to reopen it.
SW: But we have work being done by Rhys and others under that banner.
TBL: Yes, but our fundamental decision remains, and I'd prefer not to appear to reopen that.
SW: New issue?
TBL: Been thinking about that. The original issue was really about 200. We decided that means it's a document (scribe prefers information resource)
SW: Nobody's proposing to change that.
TBL: Agreed.
<DanC> (yes, this is odd... we do seem to be discussing httpRange-14 in substance, which is out of order when it's closed.)
SW: Rhys' current work seems to be building on that, not changing it.
TBL: Yes, I suppose we could do it under httpRange or a new redirections semantics.
NM: Do you want a broader issue on redirections and their semantics, or narrow to only "cacheability of 303"?
TBL: I think I'd like it broad enough to allow for discussion of a possible 203 code, should we wish to go there.
<DanC> (after a bit of noodling, I think a new issue is better. httpRange-14 is about whether http://foo/bar can refer to a car, which remains decided.)
SW: Do we allow for locations under a 20X?
TBL: Good question. Not quite sure whether a 203 would work.
SW: Dan seems to prefer new issue. Anyone against?
Silence.
SW: Soliciting suggestions for issue name and first action.
Silence.
TBL: Proposed issue name "Redirections"
NM: "HTTP Redirections"?
TBL: OK
DC: Need to hear from Norm.
NW: Aye.
SW: Have a quorum?
DC: Yes, if unanimous.
RESOLUTION: We will open a new issue named "HTTP Redirections"