Technical Architecture Group Teleconference -- 12 Aug 2010

trackbot, start meeting

<trackbot> Date: 12 August 2010

<scribe> scribenick: jar

Minutes of 15 July

RESOLUTION: approve http://www.w3.org/2001/tag/2010/07/15-tagmem-minutes

(discussion of agenda)

Privacy workshop

<Ashok> draft subject to further editing, hope to have it out in a week ... 45 participants across industry, around 43 position papers ... privacy icons idea ... may fail for the same reasons as P3P ... identify the parameters that users care most about and come up with machine readable things ... others vendors reluctant, but firefox eager to implement ... other thing: data that is gathered via API from the user, parallel to geopriv ... what secondary use, how long r

ashok: TLR on Tuesday said a workshop report will come out soon
... There's another privacy & data workshop coming up in October, somewhat different focus, W3C

note ACTION-455 remains open, we'll discuss when Dan A is around and report is out

<Ashok> Followup privacy workshop http://www.w3.org/2010/policy-ws/

TAG Status Report

noah: There's been some review and revision, any comments now?

<noah> http://www.w3.org/2001/tag/2010/sum07

noah: Propose to publish the report

No objections

RESOLUTION: Publish status report http://www.w3.org/2001/tag/2010/sum07

to be made fully public.

Announcing IRI Everywhere

<noah> Previous discussion: http://www.w3.org/2001/tag/2010/06/24-minutes#item02

noah: We were supposed to talk about this on july 15

<noah> We are to discuss: http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html [email from Adam Barth]

noah: (in Larry's absence... hmm)

(everyone reading Adam's email)

<noah> The email from Adam Barth quotes Roy Fielding:

<noah> "Some people have proposed that most of that pre-processing be added

<noah> to the IRIbis spec, but I have seen no evidence to suggest that

<noah> such pre-processing is even remotely standardizable (it seems to

<noah> be different for every input context). If you can demonstrate or

<noah> get agreement on a single way to preprocess an input string, or at

<noah> least a few named processes (like single-ref and multi-ref), then

<noah> that would be useful.

<noah> "

<noah> ==end quote from Roy==

ht: Bullet number 2 "I object to HTML5 being blocked in the IRIbis working group..." - isn't this what Larry is trying to do in the IRIbis WG?

<ht> I'm ready to discuss, to the effect that we shouldn't discuss

<noah> NM: But that's offered just as rationale...then change proposal itself stands on its own, no?

<noah> HT: Not convinced...this seems fundamental to what LM et. al. are trying to do, no?

ht: I conclude we can't take this further without Larry, since the rationale depends crucially on the claim that IRIbis is holding things up, and we need to hear from him on that

noah: HTML is representative of a class of languages that will need this kind of processing - not unique

<noah> In effect, this change proposal urges the working group to adopt Roy's

<noah> proposal

noah: "In effect, this proposal urges the WG to adopt Roy's proposal" - what does this have to do with IRIbis?

ht: Roy's experience is directly contradicted by XML Core experience (system identifiers, LEIRIs, etc.) - there's quite a bit of commonality

<Zakim> ht, you wanted to disagree based on XML COre WG experience

ht: we discontinued work on a separate spec because IRIbis was willing to take it on... I think Roy's wrong

noah: Not sure the facts support what you [ht] say. The question is whether the place to specify common behavior is in IRI spec, [or someplace else]

<noah> Sure it defined what people type, to put it circularly, in the particular cases where someone's spec called for a string that was in fact a URI.

<timbl> People write?

<noah> What it does not do is outlaw the converse, I.e., for specs to call for strings that require processing to get to a URI.

<noah> (of course, there's usually at least UTF8 interpretation or some such)

ht: URI is only about what's in an HTTP request. Adam's claim seems to be that anything else needs to be in HTML5 spec

(scribe may have mangled that)

noah: Are we missing a window for constructive comments if we wait for Larry?

<ht> http://www.w3.org/html/wg/tracker/issues/56

ht: Issue 56 is listed as open. Discussed 15 July. No apparent countdown.

<noah> action-448?

<trackbot> ACTION-448 -- Noah Mendelsohn to schedule discussion of http://lists.w3.org/Archives/Public/public-html/2010Jun/0394.html on 26 August (followup to 24 June and 12 August discussion) -- due 2010-08-24 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/448

Developer feedback camp

noah: Nervous about this

<noah> action-454?

<trackbot> ACTION-454 -- Daniel Appelquist to take lead in organizing possible Web apps architecture camp / workshop / openday -- due 2010-07-22 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/454

waiting on Dan...

Redirecting from secondary resource to secondary resource

<noah> ACTION-452?

<trackbot> ACTION-452 -- Noah Mendelsohn to schedule, when Tim is available, discussion of redirection from A#B to C#D -- due 2010-08-17 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/452

<noah> http://www.w3.org/2001/tag/2010/07/15-tagmem-minutes.html#item04

<noah> <timbl> ? GET A#B -> 307 C#D ??

<noah> JAR: We were confused in the minutes. It's wrong in the minutes (except in one place), and wrong in today's agenda.

jar: Meaning of A#B where A redirects to C#D

<timbl> ? GET A --> 307 C#D ??

jar: 307 C#D not allowed in 2616, but is allowed in HTTPbis

<timbl> in the LocatioN: field

<timbl> Why then did they change it?

<noah> JAR: In the location header, 307 C#D not allowed in 2616, but is allowed in HTTPbis

<Yves> GET /chapter2 => 301 /entirebook#chapter2

<noah> Is this the first precedent for fragment ids being part of an on-the-wire HTTP reference, as opposed to client-side only?

HT: The change to HTTPbis seems reasonable and meaningful -- if there's no # in the original URI(ref)

timbl: I'm surprised that this got changed, since all clients will have to be updated

HT: HTTPbis isn't final, I'm just saying why it is plausible

<timbl> The purl server will return this in practice

yves: Depends on media type, so if you have redirection [to C#D] media type will matter [?]

<Zakim> noah, you wanted to say seems somewhat antithetical to KISS

(scribe not getting what Yves is saying)

noah: Until now, the Location: header has been something you can do a GET on, right?

<timbl> No precedents already there

noah: Now we're going to have to distribute responsibility for resolution

<noah> ok

<Yves> Yves: fragment processing depends on the media type, also the kind of fragment iss to take into account, absolute references, or relative references (like in xpointer), but the mechanism has to be defined somewhere

<noah> Well, as I said, if there is on precedent, then this is introducing architectural as well as code complexity. I basically always assumed that HTTP was oblivous to fragids.

<timbl> $ curl -I http://purl.org/dc/terms/title

<timbl> HTTP/1.1 302 Moved Temporarily

<timbl> Date: Thu, 12 Aug 2010 17:44:26 GMT

<timbl> Server: 1060 NetKernel v3.3 - Powered by Jetty

<timbl> Location: http://dublincore.org/2008/01/14/dcterms.rdf#title

<timbl> Content-Type: text/html; charset=iso-8859-1

<Yves> Location was absoluteURI, not relative ones

<noah> This violates RFC 2616?

So we're discussing what http://purl.org/dc/terms/title#zebra would mean

<noah> RFC 2616 is the current RFC.

<timbl> If in RDF you follow the latter thing you get a document which tells you about C#D

<timbl> The document C tells you about A

<timbl> This example does NOT work in Tabulator

noah: And what DC does violates 2616

<timbl> A 303 to C would have been perfect

jar: 303 Location: http://dublincore.org/2008/01/14/dcterms.rdf#title not permitted by 2616

<timbl> Location: http://dublincore.org/2008/01/14/dcterms.rdf

<timbl> would have been fine

jar: yes

<timbl> and then that document tells you about A#B

timbl: The new PURL software lets you do bulk 303 redirects

jar: Has it [the new software] been deployed at purl.org?

<noah> I just noticed that Paul Cotton is asking whether we have input on their distributed extensibility change proposal. Input closes within the next day or so.

<timbl> http://purl.org/docs/help.html#purls

<noah> We should briefly discuss that after we wrap this discussion.

timbl: I propose HTTPbis is wrong. We don't want clients to get confused.
... There is a perfectly good alternative for OCLC to use, namely 303

<timbl> http://purl.org/docs/help.html#purlmodify

<Yves> Introducing fragment in Location is http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6

timbl: If HTTP Location: is going to change we need a very good reason

Yves: Best thing would be for me to track down discussion so far in HTTP mailing list

<Yves> another pointer http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0103.html

<scribe> ACTION: Yves to locate past HTTP WG discussion on Location: A#B change, and make the TAG aware of it [recorded in http://www.w3.org/2010/08/12-tagmem-irc]

<trackbot> Created ACTION-456 - Locate past HTTP WG discussion on Location: A#B change, and make the TAG aware of it [on Yves Lafon - due 2010-08-19].

<timbl> ^ doc about how to change your PURL.

action-456 due 2010-08-17

<trackbot> ACTION-456 Locate past HTTP WG discussion on Location: A#B change, and make the TAG aware of it due date now 2010-08-17

Distributed extensibility and HTML

noah: Deadline = tomorrow, from Paul Cotton

<noah> On 5 August I sent out: http://lists.w3.org/Archives/Public/www-tag/2010Aug/0002.html

<noah> No response.

<noah> Paul Cotton says input needed tomorrow, 13 August: http://lists.w3.org/Archives/Public/www-tag/2010Aug/0006.html

timbl: The call is for people inside the HTML WG to stand up for particular proposals, right?

ht: Of the 5 proposals, 2 were precursors, leaving 3 proposals, one of which is status quo. All 3 have champions.

<noah> Rob Ennals

<timbl> 4 obsoletes 1 and 2

ht: Proposals X and Y were put forward by Rob Ennals. 4 obsoletes 1 and 2.

<noah> #4 supercedes #1 and #2

<noah> All other proposals have advocates.

noah: Suggest: Thanks for soliciting input, our concern was that all proposals have advocates, and they seem to.

<noah> ACTION: Noah to respond to Paul Cotton indicating TAG awareness that all current proposals have advocates, and will therefore not be dropped. [recorded in http://www.w3.org/2010/08/12-tagmem-irc]

<trackbot> Created ACTION-457 - Respond to Paul Cotton indicating TAG awareness that all current proposals have advocates, and will therefore not be dropped. [on Noah Mendelsohn - due 2010-08-19].

The HTML-XML Chasm

<ht> http://www.w3.org/2001/tag/group/track/issues/54

<timbl> HTML and XML divergence

<timbl> Proposed new issue

<timbl> source document

<ht> Is the indefinite persistence of 'tag soup' HTML consistent with a sound architecture for the Web? If so, what changes, if any, to fundamental Web technologies are necessary to integrate 'tag soup' with SGML-valid HTML and well-formed XML?

<timbl> 54 is a subissue of the divergence isue

<noah> htmlXML-66?

<noah> Title: Interoperability of HTML and XML

<noah> Product: HTML 5 Review

<noah> Shepherd: Tim?

<noah> Title: HTML and XML Divergence

<noah> ISSUE-66?

<trackbot> ISSUE-66 -- The role of MIME in the Web Architecture -- open

<trackbot> http://www.w3.org/2001/tag/group/track/issues/66

<noah> ISSUE-67?

<trackbot> ISSUE-67 -- HTML and XML Divergence -- raised

<trackbot> http://www.w3.org/2001/tag/group/track/issues/67