Technical Architecture Group Teleconference

noah: we won't meet next two weeks, will meet Jul 12

noah: we are missing minutes from 12th & 14th of F2F
... we'll be talking about who can carry forward work on Publishing & Linking
... we'll then talk through the rest of the fragids draft
... anything else?

<ht> I'm working on my minutes for 12th (Tuesday)

Ashok: can we talk about the acct: URI scheme?

noah: we did have some discussion at F2F
... if we don't get to it today, we'll try to schedule another chat about it

Copyright and Linking: ISSUE-25 (deepLinking-25): Can publication of hyperlinks constitute copyright infringment?

NM: Larry and Ashok have both expressed an interest

NM:Goal is to decide who will pick up from Jeni...both Ashok and Larry have expressed interest.

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.
... 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.
... On that basis, the sense was that it is quite close to being ready to publish.

<jar> 0

<darobin> +1

<ht> 0

ashok +1

NM: OK, that's two. Not great, but at least we have some informed independent opinions.

AM: I disagreed with some of the messages. I would like a stronger message.
... 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.

<jar> no, not just aligning terminology

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.

<Yves> strong +1

JT: We did talk about having a separate {article, blog post, whatever} in which we might express stronger opinions.

<jar> agree with "the opinion expressed" but not "our role should be"

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.

<Zakim> Important for TAG, willing to work on it in 'pick a victim' sense

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.

AM: I have a very specific 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"

<Zakim> JeniT, you wanted to say I liked what Jonathan said in one of his emails

<JeniT> http://lists.w3.org/Archives/Public/www-tag/2012Jun/0071.html

<Ashok> Jonathan, I did read your mail

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.

<jar> Maybe we can be explicit about the "chilling effects" idea

<Zakim> noah, you wanted to express nervousness with Ashok's request

NM: I'm more reluctant than Ashok to go as far as he wants to go. Talking about something seditious is a term of art in the legal community. I think we want to steer clear of those abstractions. I think we should focus on what we can talk about, around technology and the way the web works.

NM: and explain how if people pass laws that conflict with use of the web, there will be issues to resolve. Anything that talks about what's legal is limited in jurisdiction. I'm even nervous about technical protocols that indicate permissions.

<jar> Not just law, also judgment and contract!

JAR: I think I disagree with NM
... There are some ideas that are not legal by nature
... e.g. 'license'

JAR: We don't always have to shy away from them
... We all make judgements

<noah> Do all jurisdictions have licenses? I would have thought the Web is used in areas where legal frameworks are less developed, or different.

<noah> 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

JAR: If an authority tries to impose conditions, there's a problem if no objective criteria exist for determining if those conditions apply
... So I think we can make useful contribution in such spaces, w/o talking specifically about the law in any particular jurisdiction

NM: We have to be careful about not appearing to make claims across jurisdictions

JAR: We can include disclaimers, but it is certainly possibly to talk about these things without talking about law

<jar> You can say: If a decision requires human judgment, it can't be made by a computer

AM: I want to hear what JAR thinks we can say

YL: Discussing things associated with law and jurisdiction, you are moving from the technical to the political
... And I think expressing a political opinion is wrong for the TAG

<jar> 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

NM: So, no interest in abandoning
... JT suggested we proceed by coming up with a document, then setting up a Community Group to take it forward
... Originally we discussed have a document which we the TAG could use to get visibility from various policy-making groups

NM: So, agreed that we should find some editors, and then handing off to a CG?

[nem. con.]

<JeniT> worth re-reading the minutes at http://www.w3.org/2001/tag/2012/04/02-minutes#item05

NM: Ashok?

AM: I would be happier picking this up if we can say slightly stronger things
... I need to talk offline with JAR before being sure

NM: OK, regretfully, we have to pend the editor decision

<JeniT> see what Larry says too, I think he's happy with the current direction

JAR: I have other things ahead of this, but if all else fails, I'll take it on

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

<jar> +1 ashok as editor for next 3 weeks

<ht> +1

NM: Please, AM, reach out to LM and let him know where you are going
... Best way to help us decide would be for AM to draft some fragments of text indicating the new direction

<noah> ACTION-541?

<trackbot> ACTION-541 -- Jeni Tennison to helped by DKA to produce draft on technical issues relating to copyright/linking -- due 2012-08-01 -- OPEN

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

<noah> close ACTION-541

<trackbot> ACTION-541 Helped by DKA to produce draft on technical issues relating to copyright/linking closed

ACtION Ashok with help from JAR to work on a plan for taking a slightly stronger version of the Copyright and Linking draft forward

<trackbot> 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].

<noah> ACTION: Noah to find editor for copyright and linking after group reviews Ashok's proposals on stronger messages - Due 2012-08-12 [recorded in http://www.w3.org/2001/tag/2012/06/21-minutes.html#action01]

<trackbot> 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].

trackbot, action-727 due 2012-07-10

<trackbot> 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

<noah> ACTION-728 Due 2012-07-12

<trackbot> ACTION-728 find editor for copyright and linking after group reviews Ashok's proposals on stronger messages due date now 2012-07-12

Fragment Identifiers

JT: We got to just before section 4 in our review at the recent F2F

<jar> N.b. the latest version at http://www.w3.org/2001/tag/doc/mimeTypesAndFragids is not what's linked from the minutes

<jar> May 28 vs. June 12

JT: We had mostly focussed on the Best Practices, but with some need for clearer exposition

<JeniT> http://www.w3.org/2001/tag/doc/mimeTypesAndFragids.html#structures

HST: When we get to the right time, I'll have some things to say

<noah> Are we in section 3 or 4?

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

<noah> I'm a little troubled by:

<noah> Best Practice 8: Do Not Specify Use of Plain Name Fragment Identifiers

<noah> Structured syntax suffix registrations should not define processor behaviour for plain name fragment identifiers.

HST: Ah, I hadn't remembered that -- yes, that would be good

JT: Yes, that's the one I agreed to change

NM: So what would the new approach be

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

NM: Why are we saying 'should not' in the first place?

HST: Likewise

NM: Still not sure why this says SHOULD NOT

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
... So that we want them to be left for individual media types
... 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

NM: I'd be happier with a tradeoff, so that we should the pros and cons
... [ two sides of the coin ]
... Then suffix reg. for plainnames would be an example

<jar> "please don't conflict with what anyone else does" is an unfollowable request

NM: I think it's OK to say this in a generic suffix case

HST: 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 a barename doesn't refer per the suffix, then it's free to be given a referent by a "junior" registration

HST: That's where I thought we ended up.

HST: HT: I hear you say you're going to review the Nice/Sophia minutes, and that's enough for me.

HST: I'm happy based on your commitment to review

HST: I have not made progress with Chris Lilley. The IETF work on suffix registrations is going to be approved within the week.

HST: I feel its reference to +xml is defective, but unless 3023bis is republished right now, there's nothing to ask the IETF folks to refer to.

<jar> It has to be understood that required-error is not a referent

<JeniT> jar, I don't understand what you just said?

JT: Section 4 -- Don't use a syntax that might overlap with one already in use
... E.g. media frag chose their syntax to avoid overlap with XPointer
... That was BP 10
... BP 11:

<JeniT> 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.

JT: This enables e.g. conneg

<jar> How is a spec writer supposed to know what the existing structures are?

<jar> what constitutes due diligence?

AM: What does the word 'structures' mean here?

<JeniT> A fragment identifier structure is a defined set of fragment identifier syntax, semantics and processing requirements

AM: Structure should be reusable across same syn and sem. . .

JT: Yes
... YL, any suggestions wrt media frag?

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

JT: Was there any discussion of fallback?

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?

HST: See JAR's comments above?

JT: Not sure -- you have to look at the media types you are targetting, and their fragid structures, and look for conflicts

YL: But until the new rules are in place, registrations don't always show the frag structure syntax

HST: When you're trying to allow for generalization, how do you know who might be interested?

HST: Seems you should look at other media type registrations targeted at similar information

JT: Yes, so consider the SVG XPointer scheme, which I thought was unnecessarily restricted just to SVG
... When it was targetted at image regions
... So perhaps it should/could have been more generic
... Section 5
... Best practices for writing documents which include identifiers [anchors] or which write URIs which use fragments:

<JeniT> 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.

JT: This just reiterates what it says in Web Arch

NM: Word-for-word?

JT: No, restatement

HST: Web Arch doesn't have the second clause, I don't think

JT: Right

HST: I like it. . .

NM: Just wondering if this is in scope. . .
... "same name"?
... Does that mean id=, or something referenced from a URI with a fragid?

HST: Referencable

JT: I was trying to pull everything about fragment identifiers into one place

NM: If it said "identifiable with a fragment identifier" instead of "same name"

HST: I now hear this as a friendly amendment

NM: As written this could apply to CSS selectors

JT: I'll fix that
... BP 13 is around scripting -- I think this is quite important:

<JeniT> 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.

JT: This is trying to articulate a hierarchy -- who gets first priority in interpreting a fragment id

<noah> Suggest: where scripts use fragment ids to track application state, such usage should be provided for in the pertinent media-type registration.

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

NM: The phrase "normal processing of fragment identifiers" troubles me

<JeniT> talk about identifying fragments rather than normal processing

NM: The second sentence seems backwards to me
... It should say that the media-type reg should provide for this use
... So e.g. the application/html media-type reg should say "JS can use syntax ... for app state"

HST: Hold on

HST: That's just overly optimistic, isn't it?
... But I take your point

<JeniT> "adhere to the guidelines specified in the media type"

<JeniT> "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"

<noah> http://www.w3.org/2001/tag/doc/IdentifyingApplicationState#NewSpecs

<noah> 6.1 New Specifications

<noah> 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.

<noah> 6.2 Existing Specifications

<noah> 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

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"

AM: Agree with NM -- we took a direction, we should follow up on it

NM: JT?

JT: OK, I will rephrase, and refer back to BP 4

NM: The State finding may be useful

JT: Yes
... Section 5.2 is for people creating fragids
... Talks about structures they could use

<noah> 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.

JT: names or semantically-based [e.g. SCDs] or syntactically based (e.g. XPointer)

<JeniT> Authors should not use URIs with syntax-based fragment identifiers unless the base URI addresses a resource with a single format

HST: Is it clear that "with a single format" means not conneged

<noah> Best Practice 14: Do Not Use Syntax-Based Fragment Identifiers with Multiple Content-Negotiated Formats

<noah> Authors should not use URIs with syntax-based fragment identifiers unless the base URI addresses a resource with a single format

HST: 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.

JT: linked data do it RDF+XML to Turtle and XML?

NM: Non RDF XML?

JT: No, RDF+XML, Turtle, and HTML

NM: I think this is OK, given the clear and rather narrow definition of syntax-based IDs at the top

HST: 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?

JT: Isn't it OK if they don't resolve?

HST: Somewhere in the record it says that Jonathan and I have disagreed on the interpretation of Webarch on exactly that point.

HST: My take is OK, since turtle doesn't give anchors for barenames. Odder with comparison with RDF+XML

NM: "except when it's possible to be sure that all fragments will resolve consistently across formats"
... I was heading for pushing this back into 5.1

JT: Already there as BP 12

NM: How do I know? I'm an author about to write an href -- I have to 2nd-guess the source?
... How do I know whether it's going to conneg or not?

JT: If there's an extension, e.g. .xml, then you know conneg isn't going to happen

NM: But we have said in Auth Metadata to not do that!

JT: Well, that's just one example, there are many ways you might get this information

HST: I'd like to come back to this one

NM: Are we under pressure here?

<noah> From: http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalicious

JT: I would like to take the input I have and get a new draft out
... There is some pressure

<noah> 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.

HST: The suffix-reg IETF draft is due out any day now, but we can't do anything with that in any case
... The main media type IETF draft is not closing right away

<noah> ACTION: Jeni to do new draft of fragids finding - Due 2012-07-10 [recorded in http://www.w3.org/2001/tag/2012/06/21-minutes.html#action02]

<trackbot> Created ACTION-729 - do new draft of fragids finding [on Jeni Tennison - due 2012-07-10].