16:59:46 RRSAgent has joined #tagmem 16:59:46 logging to http://www.w3.org/2012/06/21-tagmem-irc 16:59:48 RRSAgent, make logs public 16:59:48 Zakim has joined #tagmem 16:59:50 Zakim, this will be TAG 16:59:50 ok, trackbot; I see TAG_Weekly()1:00PM scheduled to start in 1 minute 16:59:51 Meeting: Technical Architecture Group Teleconference 16:59:51 Date: 21 June 2012 17:01:32 darobin has joined #tagmem 17:01:33 TAG_Weekly()1:00PM has now started 17:01:40 +Ashok_Malhotra 17:01:43 +??P6 17:02:06 noah has joined #tagmem 17:02:10 +Noah_Mendelsohn 17:02:18 zakim, noah_mendelsohn is me 17:02:18 +noah; got it 17:02:25 zakim, who is here? 17:02:25 On the phone I see Ashok_Malhotra, JeniT, noah 17:02:26 On IRC I see noah, darobin, Zakim, RRSAgent, JeniT, Ashok, timbl, trackbot, Yves, plinss 17:02:40 jar has joined #tagmem 17:02:44 +??P8 17:02:52 Zakim, ??P8 is me 17:02:52 +darobin; got it 17:03:06 +??P9 17:03:18 ht has joined #tagmem 17:03:29 zakim, who is here? 17:03:29 On the phone I see Ashok_Malhotra, JeniT, noah, darobin (muted), ??P9 17:03:30 On IRC I see ht, jar, noah, darobin, Zakim, RRSAgent, JeniT, Ashok, timbl, trackbot, Yves, plinss 17:03:45 +plinss 17:04:18 Scribe order is: Henry Thompson, Ashok Malhotra, Yves Lafon 17:05:45 + +1.617.324.aaaa 17:05:54 + +1.617.538.aabb 17:06:01 zakim, aabb is jar 17:06:01 +jar; got it 17:07:10 Scribe: JeniT 17:07:19 noah: we won't meet next two weeks, will meet Jul 12 17:07:25 I'm working on my minutes for 12th (Tuesday) 17:07:33 noah: we are missing minutes from 12th & 14th of F2F 17:08:23 noah: we'll be talking about who can carry forward work on Publishing & Linking 17:08:42 noah: we'll then talk through the rest of the fragids draft 17:08:51 noah: anything else? 17:09:01 Ashok: can we talk about the acct: URI scheme? 17:09:18 noah: we did have some discussion at F2F 17:09:42 Ashok has joined #tagmem 17:09:54 ... if we don't get to it today, we'll try to schedule another chat about it 17:10:14 Topic: ISSUE-25 (deepLinking-25): Can publication of hyperlinks cause copyright infringment? 17:10:22 noah: Larry and Ashok have both expressed an interest 17:10:26 s/cause/constitute/ 17:10:36 topic: Copyright and Linking 17:10:39 q+ 17:10:53 Goal is to decide who will pick up from Jeni...both Ashok and Larry have expressed interest. 17:11:35 JT: We last discussed this at the F2F in France. There were some editorial matters. The biggest piece of work was to make sure the vocab and terminology was aligned with existing specs, and to reference those specs. 17:12:01 JT: We also talked about how to take it forward procedurally. The suggestion was to set up a CG after editorial changes are done, and give them the document as input. 17:12:15 JT: On that basis, the sense was that it is quite close to being ready to publish. 17:12:25 q? 17:12:43 0 17:12:45 +1 17:12:52 0 17:12:54 ashok +1 17:13:14 ack next 17:13:31 q+ to mention no-news wrt 3023bis 17:13:34 NM: OK, that's two. Not great, but at least we have some informed independent opinions. 17:13:48 AM: I disagreed with some of the messages. I would like a stronger message. 17:13:55 q+ 17:14:08 q- 17:14:16 q+ jar to use IRC instead of voice because I'm in a noise environment. Important for TAG, willing to work on it in 'pick a victim' sense 17:14:28 AM: The messages in this version are very weak. I've been told by Jeni and Jonathan that a stronger message would represent a legal opinion, which we aren't in a position to give. 17:14:33 ack next 17:15:21 no, not *just* aligning terminology 17:15:23 JT: Responsing to Ashok. Earlier drafts had stronger messages. The opinion expressed from various members, I think Jonathan and Larry especially, was that the strong statements were not appropriate. Our role should be to help align terminology between technical and legal communitites. 17:15:40 strong +1 17:15:48 JT: We did talk about having a separate {article, blog post, whatever} in which we might express stronger opinions. 17:16:09 agree with "the opinion expressed" but not "our role should be" 17:16:19 JT: I started on a draft of that, but got stuck. Couldn't think of what to say. I would support a separate document, but not here. 17:16:20 ack next 17:16:22 jar, you wanted to use IRC instead of voice because I'm in a noise environment. Important for TAG, willing to work on it in 'pick a victim' sense 17:16:24 q? 17:17:48 JAR: As I said in IRC with what Larry and I were saying before, but: I don't think we have to limit it quite to only terminology. We can go as far as saying: "this is what the technology is for...this is why we're doing all of this". If you're doing something with legal force that is in conflict there will be problems. That's a fact, not a legal opinion. 17:18:01 q+ to say I liked what Jonathan said in one of his emails 17:18:10 q? 17:19:09 AM: I have a very point in my e-mail: "if you link to material that is illegal or seditious, you MAY be prosecuted...you may want to be careful" 17:19:11 ack next 17:19:13 JeniT, you wanted to say I liked what Jonathan said in one of his emails 17:19:24 http://lists.w3.org/Archives/Public/www-tag/2012Jun/0071.html 17:19:27 q+ to express nervousness with Ashok's request 17:19:45 Jonathan, I did read your mail 17:20:07 JT: See JAR's e-mail linked above. It may be useful to have technology that allows people to express what is and isn't permitted. 17:20:11 ack next 17:20:13 noah, you wanted to express nervousness with Ashok's request 17:20:14 Maybe we can be explicit about the "chilling effects" idea 17:20:33 noah: I'm more reluctant than Ashok to go as far as he wants to go 17:20:43 ... talking about something seditious is a term of art in the legal community 17:20:53 ... I think we want to steer clear of those abstractions 17:21:14 ... I think we should focus on what we can talk about, around technology and the way the web works 17:21:35 Not just law, also judgment and contract! 17:21:36 ... and explain how if people pass laws that conflict with use of the web, there will be issues to resolve 17:21:59 ... anything that talks about what's legal is limited in jurisdiction 17:22:22 -jar 17:22:23 ... I'm even nervous about technical protocols that indicate permissions 17:22:41 +jar 17:22:50 q? 17:23:07 scribenick: ht 17:23:21 JAR: I think I disagree with NM 17:23:38 JAR: There are some ideas that are not legal by nature 17:23:43 ... e.g. 'license' 17:23:57 Do all jurisdictions have licenses? I would have thought the Web is used in areas where legal frameworks are less developed, or different. 17:23:57 ... We don't always have to shy away from them 17:24:21 ... We all make judgements 17:25:00 Mostly, I want to stop short of implying that the TAG knows anything about how license or copyright terms advertised in, say, the UK should be interpreted outside of the UK 17:25:03 q? 17:25:04 JAR: If an authority tries to impose conditions, there's a problem if no objective criteria exist for determining if those conditions apply 17:25:48 JAR: So I think we can make useful contribution in such spaces, w/o talking specifically about the law in any particular jurisdiction 17:26:11 NM: We have to be careful about not appearing to make claims across jurisdictions 17:26:45 JAR: We can include disclaimers, but it is certainly possibly to talk about these things without talking about law 17:27:00 You can say: If a decision requires human judgment, it can't be made by a computer 17:27:04 AM: I want to hear what JAR things we can say 17:27:08 ack next 17:27:35 YL: Discussing things associated with law and jurisdiction, you are moving from the technical to the political 17:27:51 ... And I think expressing a political opinion is wrong for the TAG 17:28:00 NM: So, no interest in abandoning 17:28:26 NM: JT suggested we proceed by coming up with a document, then setting up a Community Group to take it forward 17:28:53 NM: Originally we discussed have a document which we the TAG could use to get visibility from various policy-making groups 17:29:20 I am not saying we should talk about the law. We should talk about the purpose of the technology, and the fact that computer can't make judgments 17:29:36 NM: So, agreed that we should find some editors, and then handing off to a CG? 17:29:43 [nem. con.] 17:29:45 q? 17:29:57 worth re-reading the minutes at http://www.w3.org/2001/tag/2012/04/02-minutes#item05 17:30:01 NM: Ashok? 17:30:28 AM: I would be happier picking this up if we can say slightly stronger things 17:30:42 ... I need to talk offline with JAR before being sure 17:31:47 NM: OK, regretfully, we have to pend the editor decision 17:32:05 JAR: I have other things ahead of this, but if all else fails, I'll take it on 17:32:36 see what Larry says too, I think he's happy with the current direction 17:32:50 NM: Not that bad yet -- AM has said he'll try to bring a proposal forward, whose acceptance would mean he would take on the editor job 17:32:55 +1 ashok as editor for next 3 weeks 17:33:05 +1 17:33:20 NM: Please, AM, reach out to LM and let him know where you are going 17:34:29 NM: Best way to help us decide would be for AM to draft some fragments of text indicating the new direction 17:35:21 ACTION-541? 17:35:21 ACTION-541 -- Jeni Tennison to helped by DKA to produce draft on technical issues relating to copyright/linking -- due 2012-08-01 -- OPEN 17:35:21 http://www.w3.org/2001/tag/group/track/actions/541 17:35:48 close ACTION-541 17:35:48 ACTION-541 Helped by DKA to produce draft on technical issues relating to copyright/linking closed 17:35:50 ACtION Ashok with help from JAR to work on a plan for taking a slightly stronger version of the Copyright and Linking draft forward 17:35:51 Created ACTION-727 - With help from JAR to work on a plan for taking a slightly stronger version of the Copyright and Linking draft forward [on Ashok Malhotra - due 2012-06-28]. 17:36:09 ACTION: Noah to find editor for copyright and linking after group reviews Ashok's proposals on stronger messages - Due 2012-08-12 17:36:09 Created ACTION-728 - find editor for copyright and linking after group reviews Ashok's proposals on stronger messages [on Noah Mendelsohn - due 2012-08-12]. 17:36:37 trackbot, action-727 due 2012-07-10 17:36:37 ACTION-727 With help from JAR to work on a plan for taking a slightly stronger version of the Copyright and Linking draft forward due date now 2012-07-10 17:36:42 ACTION-728 Due 2012-07-12 17:36:42 ACTION-728 find editor for copyright and linking after group reviews Ashok's proposals on stronger messages due date now 2012-07-12 17:37:00 Topic: Fragment Identifiers 17:37:10 -noah 17:37:32 q+ to mention no-news wrt 3023bis 17:37:35 +noah 17:37:55 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-05-28.html#structures 17:38:08 JT: We got to just before section 4 in our review at the recent F2F 17:38:18 N.b. the latest version at http://www.w3.org/2001/tag/doc/mimeTypesAndFragids is not what's linked from the minutes 17:38:44 May 28 vs. June 12 17:38:45 JT: We had mostly focussed on the Best Practices, but with some need for clearer exposition 17:38:52 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids.html#structures 17:39:33 q+ ht2 to remind that we have _not_ agreed about the proposed BP about +xml 17:39:56 ack ht 17:39:56 ht, you wanted to mention no-news wrt 3023bis 17:40:11 HT: When we get to the right time, I'll have some things to say 17:41:28 Are we in section 3 or 4? 17:41:32 JT: We did agree some redrafting -- in particular wrt barenames, I will say something to the effect that if a suffix scheme says something about barenames, particular schemes should respect that 17:41:43 I'm a little troubled by: 17:41:44 Best Practice 8: Do Not Specify Use of Plain Name Fragment Identifiers 17:41:44 Structured syntax suffix registrations should not define processor behaviour for plain name fragment identifiers. 17:41:46 HST: Ah, I hadn't remembered that -- yes, that would be good 17:42:08 JT: Yes, that's the one I agreed to change 17:42:20 NM: So what would the new approach be 17:43:19 JT: Structured SSR should not define processor behaviour for plain name fragment identifiers, but if the do it should be in line with that basis media type -- e.g. +xml is OK, based on /xml 17:43:48 NM: Why are we saying 'should not' in the first place? 17:43:52 HST: Likewise 17:43:53 NM: Still not sure why this says SHOULD NOT 17:44:35 JT: I will revisit what we said in Nice, but my recollection was that plain names were special, and that they are good for referencing things at the level of a particular media type 17:44:54 ... So that we want them to be left for individual media types 17:45:30 JT: Particularly if you are interpreting from multiple media types, all of which have said things about plainnames, then you don't have the freedom you need 17:45:52 NM: I'd be happier with a tradeoff, so that we should the pros and cons 17:46:11 ... [ two sides of the coin ] 17:46:42 NM: Then suffix reg. for plainnames would be an example 17:46:48 … "please don't conflict with what anyone else does" is an unfollowable request 17:47:13 NM: I think it's OK to say this in a generic suffix case 17:48:34 HT: I also thought it was because we recognized that it was coherent to not do the land grab across the board that we were happy to have suffix registrations say what they do. We thought it was important that suffix registrations say that where barenames doesn't refer per the suffix, then it's free to be given a referent by a "junior" registration 17:48:43 HT: That's where I thought we ended up. 17:49:27 q? 17:49:28 HT: I hear you say you're going to review the Nice/Sophia minutes, and that's enough for me. 17:49:32 HST: I'm happy based on your commitment to review 17:49:36 ack next 17:49:37 q- ht2 17:49:38 ht2, you wanted to remind that we have _not_ agreed about the proposed BP about +xml 17:49:48 It has to be understood that required-error is not a referent 17:50:18 HT: I have not made progress with Chris Lilley. The IETF work on suffix registrations is going to be approved within the week. 17:50:20 jar, I don't understand what you just said? 17:50:47 HT: I feel it's reference to +xml is defective, but unless 3023bis is republished right now, there's nothing to ask the IETF folks to refer to. 17:51:13 s/it's/its/ 17:51:38 zakim, who is here? 17:51:38 On the phone I see Ashok_Malhotra, JeniT, darobin (muted), ht, plinss, Yves, jar, noah 17:51:40 On IRC I see Ashok, ht, jar, noah, darobin, Zakim, RRSAgent, JeniT, timbl, trackbot, Yves, plinss 17:53:31 JT: Section 4 -- Don't use a syntax that might overlap with one already in use 17:53:55 JT: E.g. media frag chose their syntax to avoid overlap with XPointer 17:54:19 JT: That was BP 10 17:54:48 JT: BP 11: 17:54:52 New fragment identifier structures should be defined such that they can be used across media types that share the same syntax or semantics rather than being specific to a single media type. 17:55:22 How is a spec writer supposed to know what the existing structures are? 17:55:24 JT: This enables e.g. conneg 17:55:31 … what constitutes due diligence? 17:55:49 AM: What does the word 'structures' mean here? 17:55:51 A fragment identifier structure is a defined set of fragment identifier syntax, semantics and processing requirements 17:56:20 -jar 17:56:40 AM: Structure should be reusable across same syn and sem. . . 17:56:42 JT: Yes 17:57:17 JT: YL, any suggestions wrt media frag? 17:58:10 YL: I think the non-overlap is good - there was a discussion about trying to anticipate combining when a new top-level media type comes out, but that didn't get done 17:58:22 JT: Was there any discussion of fallback? 17:59:18 YL: A bit, but only SVG was problematic, so care had to be taken wrt XPointer, but if SVG defines a new syntax themselves, _they_ will have to take care? 17:59:38 HST: See JAR's comments above? 18:00:25 JT: Not sure -- you have to look at the media types you are targetting, and their fragid structures, and look for conflicts 18:01:02 YL: But until the new rules are in place, registrations don't always show the frag structure syntax 18:01:20 -darobin 18:01:42 HT: When you're trying to allow for generalization, how do you know who might be interested? 18:02:12 HT: Seems you should look at other schemes(?) targeted at similar information 18:02:58 JT: Yes, so consider the SVG XPointer scheme, which I thought was unnecessarily restricted just to SVG 18:03:09 ... When it was targetted at image regions 18:03:20 ... So perhaps it should/could have been more generic 18:03:41 s/similar information/similar information [HST fill in here]/ 18:03:49 JT: Section 5 18:04:35 JT: Best practices for writing documents which _include_ identifiers [anchors] or which write URIs which _use_ fragments: 18:04:37 Publishers should ensure that structures with the same name in two content-negotiated representations have the same semantics. Equally, where two structures in content-negotiated representations have the same semantics, they should be given the same name. 18:05:02 JT: This just reiterates what it says in Web Arch 18:05:11 NM: Word-for-word? 18:05:19 JT: No, restatement 18:05:44 HST: Web Arch doesn't have the second clause, I don't think 18:05:45 JT: Right 18:05:50 HST: I like it. . . 18:06:20 NM: Just wondering if this is in scope. . . 18:06:44 NM: "same name"? 18:07:05 NM: Does that mean id=, or something referenced from a URI with a fragid? 18:07:12 HST: Referencable 18:07:50 JT: I was trying to pull everything about fragment identifiers into one place 18:08:12 NM: If it said "identifiable with a fragment identifier" instead of "same name" 18:08:31 HST: I now here this as a friendly amendment 18:08:44 NM: As written this could apply to CSS selectors 18:08:47 JT: I'll fix that 18:09:16 JT: BP 13 is around scripting -- I think this is quite important: 18:09:18 Scripts should not override the normal processing of fragment identifiers. Script-specific fragment identifiers that identify application state should be encoded using a syntax that does not conflict with that specified for the media type. 18:09:55 q? 18:09:57 JT: This is trying to articulate a hierarchy -- who gets first priority in interpreting a fragment id 18:10:52 Suggest: where scripts use fragment ids to track application state, such usage should be provided for in the pertinent media-type registration. 18:11:35 JT: If you are going to interpret something identified by a fragment, do it per the media type(s). Thus if you are creating/exploiting for/from script usage, don't trespass on the media-type-registered syntax 18:12:04 NM: The phrase "normal processing of fragment identifiers" troubles me 18:12:45 talk about identifying fragments rather than normal processing 18:12:56 NM: The second sentence seems backwards to me 18:13:20 NM: It should say that the media-type reg should provide for this use 18:13:53 ... So e.g. the application/html media-type reg should say "JS can use syntax ... for app state" 18:14:13 HST: Hold o 18:14:19 s/Hold o/Hold on/ 18:14:32 "adhere to the guidelines specified in the media type" 18:15:29 "if the media type doesn't give scope for scripts to do stuff and you really need to, at least don't clash with the media type syntax" 18:16:32 http://www.w3.org/2001/tag/doc/IdentifyingApplicationState#NewSpecs 18:16:38 6.1 New Specifications 18:16:38 All media type specifications and registrations, especially for new types, must specify fragment identifier semantics for both static use and use in active content as appropriate. The text/html and application/xhtml+xml media types defined for HTML5 need to define the use of fragment identifiers with active content. 18:16:58 6.2 Existing Specifications 18:16:58 For media types that accept "active content", like HTML and SVG, the definition should be extended to acknowledge the fact that fragment identifiers might also be used (if not in contradiction with the 'static' use of those fragment identifiers) for programmatic purposes. The media type registration needs to say how fragment identifiers are used as parameters by the active content and how they may be used to identify the portion of the state that is reprodu 18:17:50 HST: That's just overly optimistic, isn't it? 18:18:20 HST: But I take your point 18:19:19 NM: Why should we change direction now? Everything from 3986, through Web Arch and the Self-Describing Web, puts a stake in the ground and says "say what you are going to do, and don't do what you haven't said" 18:19:31 AM: Agree with NM -- we took a direction, we should follow up on it 18:19:39 NM: JT? 18:20:18 JT: OK, I will rephrase, and refer back to BP 4 18:20:44 NM: The State finding may be useful 18:20:47 JT: Yes 18:21:42 JT: Section 5.2 is for people creating fragids 18:21:57 ... Talks about structures they could use 18:22:11 Scripts should not override the normal processing of fragment identifiers. --> Scripts should respect(?) the normative interpretation of fragment identifiers, as specified in the media type registration for the Content-type. 18:22:35 ... names or semantically-based [e.g. SCDs] or syntactically based (e.g. XPointer) 18:22:38 Authors should not use URIs with syntax-based fragment identifiers unless the base URI addresses a resource with a single format 18:23:19 HST: Is it clear that "with a single format" means not conneged 18:23:23 Best Practice 14: Do Not Use Syntax-Based Fragment Identifiers with Multiple Content-Negotiated Formats 18:23:23 Authors should not use URIs with syntax-based fragment identifiers unless the base URI addresses a resource with a single format 18:23:54 HT: I have concerns about taking conneg too seriously in this doc. It's not being done much. I'd be happier if I knew a constituency regularly producing conneg'd data. 18:24:17 JT: linked data do it RDF+XML to Turtle and XML? 18:24:23 NM: Non RDF XML? 18:24:33 JT: No, RDF+XML, Turtle, and HTML 18:25:35 I think this is OK, given the clear and rather narrow definition of syntax-based IDs at the top 18:26:12 HT: Yes, but anyone doing this is almost certainly breaking the rules wrt/ barenames? E.g. if I have IDs on my HTML divs, I can't reflect that in Turtle? 18:26:22 JT: Isn't it OK if they don't resolve? 18:26:43 HT: Somewhere in the record it says that Jonathan and I have disagreed on the interpretation of Webarch on exactly that point. 18:27:13 HT: My take is OK, since turtle doesn't give anchors for barenames. Odder with comparison with RDF+XML 18:28:22 NM: "except when it's possible to be sure that all fragments will resolve consistently across formats" 18:29:52 NM: I was heading for pushing this back into 5.1 18:29:59 JT: Already there as BP 12 18:30:45 NM: How do I know? I'm an author about to write an href -- I have to 2nd-guess the source? 18:30:59 ... How do I know whether it's going to conneg or not? 18:31:31 JT: If there's an extension, e.g. .xml, then you know conneg isn't going to happen 18:31:45 NM: But we have said in Auth Metadata to not do that! 18:32:06 JT: Well, that's just one example, there are many ways you might get this information 18:32:27 HST: I'd like to come back to this one 18:32:48 NM: Are we under pressure here? 18:33:15 From: http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalicious 18:33:27 JT: I would like to take the input I have and get a new draft out 18:33:31 -Ashok_Malhotra 18:33:34 ... There is some pressure 18:33:52 From: http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalicious Although a URI suffix such as .jpeg or .exe plays no role in establishing the media type of a Web resource, such suffixes are often significant in operating system filenames. This inconsistency can be confusing to users, and may in some cases be exploited by malicious Web sites to cause harm. 18:34:19 HST: The suffix-reg IETF draft is due out any day now, but we can't do anything with that in any case 18:34:40 -plinss 18:34:40 ... The main media type IETF draft is not closing right away 18:35:00 -ht 18:35:03 ACTION: Jeni to do new draft of fragids finding - Due 2012-07-10 18:35:03 Created ACTION-729 - do new draft of fragids finding [on Jeni Tennison - due 2012-07-10]. 18:35:14 -Yves 18:35:15 -noah 18:35:17 -JeniT 18:35:17 TAG_Weekly()1:00PM has ended 18:35:17 Attendees were Ashok_Malhotra, JeniT, noah, darobin, ht, plinss, +1.617.324.aaaa, Yves, +1.617.538.aabb, jar 18:35:26 RRSAgent, make logs world-visible 18:35:34 RRSAgent, draft minutes 18:35:34 I have made the request to generate http://www.w3.org/2012/06/21-tagmem-minutes.html ht 19:28:29 jar has joined #tagmem 20:37:22 Zakim has left #tagmem