- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Thu, 28 Jun 2012 18:59:37 +0100
- To: www-tag@w3.org
Now available at
http://www.w3.org/2001/tag/2012/06/21-minutes.html
and below as plain text.
ht
------------------
- DRAFT -
Technical Architecture Group Teleconference
21 Jun 2012
[2]Agenda
See also: [3]IRC log
Attendees
Present
Robin Berjon, Yves Lafon, Peter Linss, Ashok Malhotra, Noah
Mendelsohn, Jeni Tennison, Henry S. Thompson, Jonathan Rees
Regrets
Tim Berners-Lee, Larry Masinter
Chair
Noah Mendelsohn
Scribes
Noah Mendelsohn, Jeni Tennison, Henry S. Thompson
Contents
* [4]Topics
1. [5]Copyright and Linking: ISSUE-25 (deepLinking-25): Can
publication of hyperlinks constitute copyright infringment?
2. [6]Fragment Identifiers
* [7]Summary of Action Items
__________________________________________________________________
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>
[8]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
[9]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> [10]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
[11]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
[12]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>
[13]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>
[14]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:
[15]http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalic
ious
JT: I would like to take the input I have and get a new draft out
... There is some pressure
<noah> From:
[16]http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalic
ious 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
[17]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].
Summary of Action Items
[NEW] ACTION: Jeni to do new draft of fragids finding - Due 2012-07-10
[recorded in
[18]http://www.w3.org/2001/tag/2012/06/21-minutes.html#action02]
[NEW] ACTION: Noah to find editor for copyright and linking after group
reviews Ashok's proposals on stronger messages - Due 2012-08-12
[recorded in
[19]http://www.w3.org/2001/tag/2012/06/21-minutes.html#action01]
References
1. http://www.w3.org/
2. http://www.w3.org/2001/tag/2012/06/21-agenda.html
3. http://www.w3.org/2012/06/21-tagmem-irc
4. http://www.w3.org/2001/tag/2012/06/21-minutes.html#agenda
5. http://www.w3.org/2001/tag/2012/06/21-minutes.html#item02
6. http://www.w3.org/2001/tag/2012/06/21-minutes.html#item03
7. http://www.w3.org/2001/tag/2012/06/21-minutes.html#ActionSummary
8. http://lists.w3.org/Archives/Public/www-tag/2012Jun/0071.html
9. http://www.w3.org/2001/tag/2012/04/02-minutes#item05
10. http://www.w3.org/2001/tag/group/track/actions/541
11. http://www.w3.org/2001/tag/2012/06/21-minutes.html#action01
12. http://www.w3.org/2001/tag/doc/mimeTypesAndFragids
13. http://www.w3.org/2001/tag/doc/mimeTypesAndFragids.html#structures
14. http://www.w3.org/2001/tag/doc/IdentifyingApplicationState#NewSpecs
15. http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalicious
16. http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#confusingmalicious
17. http://www.w3.org/2001/tag/2012/06/21-minutes.html#action02
18. http://www.w3.org/2001/tag/2012/06/21-minutes.html#action02
19. http://www.w3.org/2001/tag/2012/06/21-minutes.html#action01
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
Received on Thursday, 28 June 2012 18:00:08 UTC