See also: IRC log
<Stuart> Scribe: Jonathan Rees
<Ashok> I will join in a few minutes
<Stuart> scribenick: jar
Taking up item 1 - ACTION-186 [on JAR to review CURIE draft]
jar: I think we're all done with that [action discharged].
<noah> Getting back to the CURIE question: I think my note at http://lists.w3.org/Archives/Public/www-tag/2008Oct/0024.html conveyed our formal response, and that there is nothing else I need do to fulfull my CURIE-related action.
skw: Minutes need a bit more work. Defer until next meeting.
(No volunteer to scribe, skw to find one over the week, ht maybe)
Skip item 2 "Responding to "Content Transformation Guidelines" LC Review".
skw: Please provide early feedback to XRI-TC
ht: I have reviewed the XRI as relative URIs proposal
... Seems to be OK. Their abstract/concrete distinction is sort of odd, but that's OK.
... Where do the base URIs come from?
... If base URI is a URN, as they suggest, that is odd.
<timbl> There is a suggestion to absolutize against a URN, but URNs don't use /, they use :
ht: They would be better off not going there.
<ht> Tim, yes, that's one of the problems they have already noticed
<Zakim> timbl, you wanted to mention that a lot of systems can be looked at by regarding things like mime types, isbns etc as being relative to a http: base which has not yet been defined
timbl: If XRI (relative URI) goes into an HREF, OK... otherwise (other contexts) not clear that there are many tools that will understand them [POSSIBLE SCRIBE ERROR. SEE HT COMMENT BELOW.]
<Stuart> trackbot, status
<ht> HST thinks Timbl said: If XRI as relative URI is used in href or elsewhere where a general tool will try to use them, baseURI is a problem; but in special contexts defined by host languages, they can mandate a base URI no problem -- a bit like IANA and media types, for example
<Stuart> action henry s. Send public comment to www-tag about the XRI proposal and the establishment of base URI.
<trackbot> Created ACTION-189 - S. Send public comment to www-tag about the XRI proposal and the establishment of base URI. [on Henry S. Thompson - due 2008-11-13].
skw: There are divergent views on this within the TAG.
<Zakim> noah, you wanted to ask about status of services activity process-wise
noah: The proposed work is architecturally questionable
... degree to which it duplicates HTTP
... whether URIs are used appropriately inside of EPRs
... is GET being used appropriately when used as part of the ws protocol(s)
<Zakim> dorchard, you wanted to re-iterate my proposal for charter and document status
noah: Appropriate to draw attention to the way these mechanisms are being used.
<timbl> +1
DO: It doesn't fit well into web architecture. But membership wants to go ahead. Maybe TAG should opt out?
... I've put proposals forward
(note to minutes editor: find a URL to same)
<noah> Hmm. I'm unconvinced that the TAG should set a precedent of committing NOT to review the impact of particular bits of W3C work on Web arch.
(note to minutes editor: http://lists.w3.org/Archives/Member/tag/2008Oct/0134.html )
ashok: The EPR issue has been brought up. Not useful to once again bring it up.
... I'm sympathetic to the GET / metadata issue.
... Saying the TAG won't review something might set a funny precedent
<Zakim> dorchard, you wanted to respond why it's important to bring up URIs
DO: The response was very clear: They want to use EPRs as identifiers for things - targets of operations
... They want a nonuniform interface - have opted out of web architecture
... What W3C does is not necessarily the same as web architecture. Is TAG responsible for the former or the latter?
... TAG is caught.
... I'm suggesting a path forward. By saying it's out of scope, TAG avoids compromising its position.
raman: Be careful about painting such a black and white picture. Wouldn't everyone opt out of web architecture if they could?
<Zakim> noah, you wanted to talk about setting expectations early
raman: The architecture [guardian] role needs to be earned
noah: Having a note about ws-addressing is better than not having one.
... The WS activity is working close to the core of the web
... There's value in making statements
timbl: We had a discussion, and neither group seems interested in continuing it.
<DanC> (perhaps rather than the charter and status section, it would be better to have the WG itself explain why not follow http://www.w3.org/TR/2004/REC-webarch-20041215/#pr-use-uris )
<Zakim> Stuart, you wanted to ask Dave O whether it is truely the case that EPR ref params are selective on resource or carry essential parameter that enable/facilitate access?
timbl: Maybe they've done what they have to do. [?? The scribe is maybe not quite understanding TimBL again. ??]
skw: Noah's 3 principled points are good, perhaps could be reiterated
... Are EPRs really name-like, or just subparameters?
ashok: What's the bottom line here? We're not asking them to stop; maybe we're asking them to add some words somewhere?
<noah> I think we were asked to signal early what our concerns would be. I think we should signal that they would potentially be in the 3 areas mentioned.
skw: Not clear that any proposal would command consensus of the TAG
noah: We've been asked to air issues early. Propose the 3 areas
ht: Point to, or quote, or be consistent with the way we finally settled the EPR issue
... You can take web services away from web architecture because it's not the same ballpark [what the TAG said last time?]
ashok: Why we're bringing this up again now?
<DanC> (hmm... looking thru http://www.w3.org/2001/tag/group/track/issues/47 for "what we said last time")
DO: Because they ignored us last time, and now they're reinventing HTTP using EPRs (ws-transfer...)
... Don't want to support just saying what we said before. Did no good
<Stuart> What we said before is in: http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#resourceidentification
DO: Maybe better being silent
<Stuart> "The Architecture of the World Wide Web, Volume One [AoWWW] recommends [AoWWW, Section 2] the use of URIs to identify resources. Using abstract properties of an EPR other than [destination] to identify resources is contrary to this recommendation. In certain circumstances, such a use of additional properties may be convenient or beneficial; however, when building systems, the benefits or convenience of identifying a resource using reference parameters should be care
<noah> I don't need to beat this to death. Slight preference for going on record, but I can see it either way.
noah: 1. Use EPRs appropriately 2. Don't divide the web (via 2 protocols) 3. Proper use of HTTP when it's used
<DanC> (hmm... scanning the proposed charter, I find "The referencing of metadata must allow for both EPR or URL style references. " )
DO: Not in favor of saying anything like that
<Stuart> Three possible TAG directions: Say nothing; Dave style proposal; Noah style proposal reiterating principles
<noah> I feel we're going in circles. Pros and cons of either approach have been covered. Let's pick one.
<timbl> PROPSAL 2564: Add some wording to the boilerplate in the charter indicating that the TAG is not reviewing the charter as it regards that as outside web architecture
(poll)
<timbl> I would prefer something in the boiler plate .. not do nothering
<timbl> I support proposal 2564.
<timbl> I can live with doing nothing.
<timbl> Stuart: PROPOSAL 3: Reiterate principles of web architecture on www-tag as a way of putting it on the table.
<timbl> I can live with any outcome
<Zakim> DanC, you wanted to speak to boilerplate vs engagement
danc: Better to expect the WG to consider architecture concerns
<DanC> "WS-Transfer resources are potentially identified by more than just a URI, making them unsuitable for referencing and use in other Web technologies, e.g. in the context of traditional Web links or RDF assertions."
<noah> What about relationship to HTTP?
<noah> Say anything about using methods right, etc.?
<DanC> yes, excerpted from http://www.w3.org/Submission/2006/04/Comment
danc: Propose to endorse above text (team response to submission)
<noah> How about, in addition: "Also, there is a risk, depending how WS-Transfer operates over HTTP, that WS-Transfer might not benefit from existing deployed infrastructure such as HTTP proxies."
<DanC> +1 on the amendment
RESOLUTION: Regarding the WS-Transfer submission: (1) We agree with the Team Comment (http://www.w3.org/Submission/2006/04/Comment) noting that WS-Transfer resources are potentially identified by more than just a URI, making them unsuitable for referencing and use in other Web technologies, e.g. in the context of traditional Web links or RDF assertions. (2) There is a risk, depending on how WS-Transfer operates over HTTP, that WS-Transfer might not benefit from existing deployed infrastructure such as proxies.
ACTION stuart to make the above resolution visible on www-tag
<trackbot> Created ACTION-190 - Make the above resolution [regarding the WS-transfer submission] visible on www-tag [on Stuart Williams - due 2008-11-13].
skw: How did the plenary sessions go? Any action items arise from the week?
timbl: Some TAG members attended HTML WG. Less polarization now [it seems]. Face to face meetings are good.
... Important to keep up personal ties
... (about philosophy of browser quirks)
... Maybe TAG could write up this strategy
<DanC> timbl: I learned there's a putative goal to get all the browsers to agree on the set of quirks to support and then _stop there_.
noah: Unconvinced that stripping down the big spec to get the small (authoring) spec will get a good result
... But it sounds like there's intention to do it
<DanC> a result of our modularization discussion is http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html HTML5 Specification - List of sections and corresponding work estimates Ian Hickson (Monday, 27 October)
<DanC> action-188?
<trackbot> ACTION-188 -- Dan Connolly to investigate the URL/IRI/Larry Masinter possible resolution of the URL/HTML5 issue. -- due 2008-10-30 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/188
<DanC> action-188: note 6. URL in http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html
<trackbot> ACTION-188 Investigate the URL/IRI/Larry Masinter possible resolution of the URL/HTML5 issue. notes added
danc: hsivonen said: If you can't see it in a web browser it's not on the web ...
danc: Maybe they only need identifiers that work only on the local machine?
... They need to be persistent (e.g. preferences for clock widget)
... install-time naming?
... concerns with http are in part security related
danc would like to close ACTION-187
<timbl> http://www.w3.org/2001/tag/group/track/issues/61
<DanC> (checking http://esw.w3.org/topic/UriSchemes/jar ...)
timbl: (another example) Resource-within-jar-file URIs?
<timbl> I think the delimiter was /!/ or something
<DanC> (wild... http://java.sun.com/developer/onlineTraining/protocolhandlers/ discusses cvs: and win32-registry: )
timbl: Consider making ! a special separator in URIs?
... inspired by the jar example.
<Stuart> Tim... some jar:...!... stuff at: http://java.sun.com/javase/6/docs/api/java/net/JarURLConnection.html
<Stuart> The syntax of a JAR URL is:
<Stuart> jar:<url>!/{entry}
<noah> I'd like to have Henry's thoughts on good use of F2F time. I think he has a number of TAG-related things going, and also with long distance travel has good reason to set the bar high.
noah: Somewhat optimistic about making a new self-describing web draft
ashok: Would like to spend significant time on access to metadata
skw: Sure, but only if there's advance activity in this area
adjourned.