See also: IRC log
VQ: Any regrets for a call next week on 26 Sept?
NM: Hoping to be there but at risk.
VQ: Dan, can you scribe next week?
TV: Suggest we do more of call planning, regrets, etc. via email to save call time.
VQ: Let's discuss briefly at F2F.
<DanC> +1 approve http://lists.w3.org/Archives/Public/www-tag/2006Sep/att-0028/01-part
VQ: Minutes of 5 September are at http://lists.w3.org/Archives/Public/www-tag/2006Sep/att-0028/01-part
... Any objections to approving?
RESOLUTION: Minutes of 5 September 2006 at http://lists.w3.org/Archives/Public/www-tag/2006Sep/att-0028/01-part are approved.
VQ: Comments were received from Noah at http://lists.w3.org/Archives/Public/www-tag/2006Sep/0080.html
... Response from Raman was at http://lists.w3.org/Archives/Public/www-tag/2006Sep/0081.html
<Rotan> In indicating to DI chair that I could join the call, I also made comments on the issue, here - http://lists.w3.org/Archives/Member/w3c-di-wg/2006Sep/0025.html (W3C Member-only: see para.4)
VQ: We have visitors Rotan Hanrahan and Rhys Lewis
TV: Here's quick overview of goals of this work.
... I've worked in a number of related areas, such as multimodal, and we know there are multiple solutions.
... The finding is trying to set out good practices for Web content deployers.
... Specifically, we're looking for design patterns that meet particular use cases.
... Sample use case is I send a URI from desktop to cellphone, it should still get you what you need. Suggests Generic URI.
... In other cases you want a URI for a specific representation.
... Having discovered that you will need URIs for both generic and specific, the question is to get an appopriate relationship between them.
... Also need to be able to find generic URI given that you've been handed one for a specific representation.
<Rotan> My first observation - It's not just UA string that influences the representation of the resource in response to the query.
RL: We need to go from the canonical to the specific. In the practical world of mobile phones today, that mapping is very complicated. It depends on device characteristics, network parms, and user preferences, among others.
<DanC> (er... hypertext links are a pretty straghtforward way to represent the relationship, no?)
RL: You are only trying to cover the existence of a relationship, but not all the complex details.
TV: Well, having the existence and the linking is an important start.
<Rotan> There is no vocabulary that captures *all* of the possible delivery context variables that could influence the creation of representations.
RH: The number of parameters that could influence the representation is increasing all the time (bandwidth, user preference, etc.) We don't have a vocabulary for that now. There is therefore no way to write down specifics.
TV: Yes and no.
... The HTTP headers (e.g. accept) you get a degree of late vs. early binding.
... Since URIs are key, and given that there will be different streams coming back, you might want to have a different URI for each one.
RL: In commercial systems I know, it works the way you say. There is a corner case, which is where the concrete representation is being generated as a transient thing.
TV: By looking at a URL you don't know whether the referent is permanent on my desktop or not.
<DanC> (for example, /image23?size=48x48 ; you might keep the 48x48 image permanently or generate it on the fly; in either case, the URI works indefinitely.)
TV: The fact that you are creating the image on the fly doesn't keep you from generating a URI for it.
RL: Question of degree.
TV: You might have a space of many devices.
RL: Yes, thousands.
TV: Right, so canonical representation can't point to 4000 specific representations. Good point.
DC: You can use forms for thousands of links.
TV: If the canonical URI gives you a form with 3 parameters, you can use it to conjure up thousands of URLs. You can publish that form as your canonical one. It doesn't quite solve the discoverability problem, unless the agent can reverse engineer the form.
RL: Rather than hard wiring, what we're saying is there a way for an end user to provide equivalent information.
<Zakim> noah, you wanted to discuss crawling vs. convenience.
NM: URIs can be opaque.
<Zakim> Rotan, you wanted to say that perhaps one could define a small set of "virtual" devices to represent the general device space and create some UAs for these. This could be a
<DanC> NM: separate (1) existence of uris (2) [darn; leaked out already]
NM: We should be able to separately consider (1) whether there is a separate possibly opaque URI for each of the thousands of representations; (2) whether the device characteristics are manifest as metadata in the URIS; and (3) how to get transitive linking across potentially thousands of representations of the same generic resource.
<Vincent> sorry, Rotan
TV: I agree that to deploy an end-to-end solution you need to get all those device parms, but the TAG's probably not the place to do that. We should leave such things to domain experts, in this case folks like the device independence workgroups.
<Zakim> Rotan, you wanted to make previous point about virtual devices.
TV: Our piece of the puzzle should be to suggest that the URIs exist.
RH: The problem is that crawlers would have to "prompt" the servers to cause creation of the various device forms of content.
<nm> (Noah wonders why the servers wouldn't post pages populated with lots of links, possibly opaque, which if followed would cause the necessary representations to be generated.)
RH: Most of what's returned across devices is thematically consistent (e.g. you always get the weather, albeit sometimes in black and white and sometimes in color)
... Not clear that it's worth the trouble to force pregeneration of all possible combinations, given that many of the differences are likely to be uninteresting.
... So, I think a small subset of virtual devices would be sufficient.
<DanC> (I think it's pretty routine to put "nofollow" on links from generic to device-specific stuff)
<DanC> (er... or is it "noindex"... one of the old ones, not the new "nofollow")
NM: If a crawler caches a representation for a generic device, how does it serve the correct representation when queried, e.g., from some particular mobile device?
TV: To enable discoverability, available representations should be hyperlinked from the generic. In this particular case there happen to be, say, 4000. We can see ways like spanning trees or generic devices, that allow you to either aggregate them or reach them transitively. My main point is that I don't think the TAG needs to get into that level of detail. The key point of the finding is the discoverability. The rest of this is in the DI working group, mobile web initiative, etc.
RL: Wholeheartedly agree.
TV: Rhys or Rotan, please point me to any specific references I should know about.
RL: One more comment on the document: See section 2.1.1 http://www.w3.org/2001/tag/doc/alternatives-discovery.html#id2262732 . This suggests using redirection. Unfortunately, on most mobile networks, redirection is extremely expensive due to latency.
TV: You have redirection, HTTP VARY headers, and content negotiation. Use the one that works for you.
DC: Did you say this document discusses all three?
TV: People coming from different perspectives have different viewpoints on this.
VQ: Are you (Rotan or Rhys) asking for any changes?
RL: No, I wanted to hit the expense of redirects.
<Rotan> I said, look at "Thematic Consistency" concept introduced by MWI BPWG, as it is relevant to concept of multiple representations of an underlying resource. Would be good to reference it in the doc.
TV: I think the story about either virtual devices or spanning tries should be told by groups like DI.
<DanC> (when I think of concerns around this issue, I find I'm content with the way the draft currently discusses them, so I concur that few changes are needed.)
RL: I think I know where I'd want to do that.
VQ: Rhys, can you send us pointers to the firstname.lastname@example.org mailing list?
RL: Looking in particular for links to things that relate generic to specific resources, and also on Rotan's point about thematic consistency.
DC: Thematic consistency and generic resources are either synonyms or duals. Should we aim to converge terminology.
<Rotan> See - http://www.w3.org/TR/mobile-bp/#tc
RL: One is a goal, one is a technology to achieve it? Thematic consistency is an aspiration.
DC: Teach people both terms?
RL: They have different, if not completely orthogonal meanings.
DC: I'm just saying that everywhere we say generic, we could consider saying "thematically consistent"
RL: But that's not the only reason for having generics
<Rotan> The BP doc says - "A bookmark captured on one device should be usable on another, different type of device even if it does not yield exactly the same experience. If the page that was bookmarked is not appropriate for the device that is now using it, an alternative that is suitable should be provided."
NM: "thematically consistent" seems to be a pairwise relationship, but "generic" seems to be the nth+1st resource that has "aspirations" to meet the fuzzy common needs of all users.
VQ: Do you plan to change anything?
TV: Plan to add the references from Rotan and Rhys, finalize at F2F and publish. Would prefer to publish and let people read.
DC: Worth time at F2F? Maybe we're done sooner. Maybe we could be done sooner or now.
NM: What about the diagram?
TV: Oops yes. Do we still need the diagram? Are we comfortable with this finding modulo adding the references? We can discuss the diagram separately too.
DC: I think the diagram is pretty close to necessary.
TV: I would add diagram and the text.
<DanC> (I prefer publishing the diagram in SVG and in PNG and in whatever the source is (tex?))
DC: Put it at the end.
NM: or in 2.2.1
... How about dotted lines showing selective linking from specific representations to other popular specific representations (e.g. to English and French forms of a press release if links to all of them don't fit)
TV: OK, but then I'd put it at the end.
... Typographically, will it fit if I spell out the languages?
Various: Yes probably, we'll check for you.
TV: OK to discuss formatting details on email@example.com? Not worth bothering main list, I think.
VQ: I would prefer to have final version before we approve.
DC: Seems reasonable.
VQ: Can we have final version for F2F in two weeks?
TV: Yes, that's the plan.
<DanC> (I'll try to read it before the f2f, tv)
<scribe> ACTION: T.V. Raman to produce proposed final genericResources draft for approval at Vancouver F2F [recorded in http://www.w3.org/2006/09/19-tagmem-irc]
VQ: Thanks to Rhys and Rotan for joining us.
RL: Thank you.
RH: Yes, thank you!
Announcing new draft at: http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061016.html
<DanC> (it's always worth noting security issues like the .jpeg/exe bit; I'm scanning it now...)
NM: I propose we leave this for about 9 days. Ed has approved publication, but I know he's still concerned about lack of tie in between, e.g. a .jpeg suffix and image/jpeg
... I could add a warning about the security issue but would do it as warning, not a Web architecture violation.
DC: I think adding a security warning in a separate section would be good.
VQ: Publish in 9 days?
NM: Only if you want the current text. If you need new text, I'd say draft for public review in advance of F2F decision.
<scribe> ACTION: Noah to add security section on risks of serving executables as .jpeg to metadataInURI draft. For review and approval at F2F. [recorded in http://www.w3.org/2006/09/19-tagmem-irc]
According to today's agenda, potential topics for the Vancouver F2F include:
VQ: Are these the right ones?
... On generic resources and metadata we've just done status checks.
<DanC> (I concur that XMLVersioning-41 and URNsAndRegistries-50 are high priority... I can't think of anything I'd rather spend my time on... oh... except issue namespaceDocument-8 )
<nm> Suits me. I wonder if we should think about what our priorities are for months after F2F? Might be worth an hour at one point.
VQ: TV was asking about making our calls more efficient.
DC: Namespace document-8?
NW: Not quite sure I'll make progress for F2F but will try.
VQ: We just have 2 days in Vancouver.
... Please give me input on F2F agenda for next Tues.