- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 21 Jan 2003 11:14:17 +0100
- To: www-tag@w3.org
Hello,
Minutes of the 20 Jan 2003 TAG teleconf are available as
HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2003/01/20-tag-summary
=========================================================
Minutes of 20 Jan 2003 TAG teleconference
1. Administrative
1. Roll call: SW (Chair), NW, PC, DC, RF, IJ, TB, DO,
TBL. Regrets: CL.
2. Accepted 13 Jan minutes
3. Accepted this agenda
4. Next meeting: 27 Jan. NW possible regrets.
1.1 Meeting planning
* Next TAG ftf: 6-7 Feb 2003 in Irvine, CA (USA)
+ Draft agenda
+ Breakout sessions for arch doc discussions.
Who wishes to do what? Preparations for the
meeting?
[Ian]
SW: I intend to call people to help flesh out
agenda.
TB: I think that we have done reasonably well
at powering through the issues. We have done
poorly at moving the arch doc forward. We ought
to measure our success at this meeting by
progress on arch doc.
DC: Yes, a good goal.
PC: I think that we don't have agreement on
what it should look like. I think people need
to propose alternatives if unhappy with it.
[General agreement that text for the arch doc in
advance of meeting is helpful]
2. Technical
* 2.1 Linking meeting (xlinkScope-23)
* 2.2 URIEquivalence-15
2.1 Linking meeting (xlinkScope-23)
1. xlinkScope-23
1. Summary of 16 Jan special teleconference
(TAG-only).
[Ian]
IJ: I would like TAG to approve this summary to
make it public. I've heard no opposition from
other participants.
SW: Civil meeting!
TB: No consensus, but I think we made progress
in terms of identifying sources of
disagreement. Two dominate others:
1. Whether the signal is something is a link
should be inline in a document, or out of
line (e.g., as done in hlink or clink). I
think that the HTML WG feels strongly that
the external approach should be at least
allowed and possibly dominant.
2. Is it appropriate to have multiended link
through several attributes? People see design
problems; HTML WG still wants it.
[DanConn]
is that "can't live without it" requirement
about mutiple links on one element a matter of
record?
[Ian]
PC: Will summary be available?
IJ: I produced one; mostly derived from IRC
log.
NW: I think TB has identified the two most
contentious issues. I agree that the meeting
was useful, I did leave a bit frustrated that
we didn't get any farther.
IJ: I think the multiended issue was one about
attributes, not multiended-ness. Second piece
for me was more about not modifying the
instance, less about link sheets.
TB proposal on moving forward: Do nothing. An
issue has been raised. We made our arch
concerns public. They have been ably and
cogently summarized by SW. I think that the
HTML WG has the responsibility of figuring out
how to do hyperlinking in HTML, and they should
do that. Not that a bunch of issues have been
raised on the record, I think that W3C process
will mandate that the HTML WG think about them
and respond to those issues.: I think that we
wait for the HTML WG to act next.
RF: Can we come up with a generic principle for
describing why the multiple element is
perferred?
TB: There are responses from Misha, Chris, TB
on this. [And IJ recalls comments from TBL as
well]
[Attributes on attributes was mentioned]
RF: Can we include some of this in the arch
doc?
SW: E.g., in guidance on markup languages.
IJ: Anything in IETF doc?
TB: Nothing specific enough for this debate.
There is a general principle that in XML markup
languages, that if you have one, an attribute
is ok. If you have several, then elements are
preferable.
NW, TB: Good idea to talk about this in arch
doc.
PC: What about list attributes (e.g., class in
HTML)?
TB: List of attribute values is more work for
programmers.
SW: I have mixed feelings about "doing nothing"
at this point. What about producing a finding
(even if it just articulates an opinion already
expressed).
NW: I think TB's right - I'm not sure what next
steps would be right now. I can't think of any
practical step at this time.
IJ: What is scheduled at tech plenary re:
linking?
PC: We meet this week to discuss the agenda. It
was suggested that we not go into linking
issues.
SW: Liam may organize a BOF.
PC: I'd like us to have a firm bring forward
date.
TB: What about a one-line statement that we
believe that the technical issues have been
well-aired, and that those responsible for
designing hyperlink syntax in various
activities should be aware of them.
PC: I would like all parties to know where the
other parties stand.
TB: We could send pointer to SW's summary to
HTML WG comment list. I don't see benefit of
writing this down again.
SW: Does the TAG still hold the same group
opinion that we held in Sep 2002?
NW: I've not been moved.
RF: I believe that the multiend solution is
preferred if there is no backwards
compatibility issue.
IJ: TB's approach of doing nothing means - no
common syntax for links in XML?
TB: I think that xlink as written is better
than some other solutions. But some good and
plausible ideas have been suggested for
improving XLink. I might change my mind on our
previous statement in favor of an improved
solution.
[Norm]
I'd certainly sign up for the improvements
TBray describes on XLink
[Ian]
[SW summarizes for TBL, who just arrived in
meeting.]
SW: My sense is that the TAG holds pretty much
the same opinion as last Sep.
TBL: We should just keep an eye on what
develops out of our link meeting. I'm glad that
we focused on hypertext links at that meeting.
NW: I like PC's of setting a date to revisit
the question, rather than open-ended. After the
tech plenary.
Action IJ, SW: Bring xlinkScope-23 to agenda after
tech plenary meeting
2.2 URIEquivalence-15
For URIEquivalence-15, review of DC comments on How to
Compare Uniform Resource Identifiers.
[Ian]
TB summarizes comments (passing over editorial,
with which TB largely agrees).
TB on comment "er...what about 'identical'?"
TB: I agree with that DC that the draft isn't
clear enough that two pieces of software might
have different ideas of what's equivalent and
be perfectly fine.
SW: See my proposed paragraph on this point.
[Next]
TB: I think all specs in this space that are
relevant are RFCs, but I'll check.
[Next]
DC: "The TAG has decided to use the term "URI"
to include relative URI references. CRITICAL."
SW: I have a different recollection.
TB: I agree with SW on this.
IJ: Current editor's draft says:
"The current document uses the term "URI" to mean,
in RFC2396 terms, an absolute URI reference3
optionally followed by a fragment identifier. The
TAG is working actively to convince the IETF to
revise RFC2396 so that the definition of "URI"
aligns with the current document."
RF: DC's comment is incorrect.
TBL: What's the status of changes to 2396?
RF: I'm ok with the change, but requires quite
a bit of drafting.: I don't object to changing
it.
TBL: I think this is the time to do it. RF, do
you need help. Please, please, please make this
change.
Proposed Action TB: Request that the change be
made on the URI list.
RF: Send URI Equivalence to URI list as well.
Action TBL: Send email to uri@w3.org requesting
terminology change.
[Next]
About: example://a/b/c/%7A and
eXAMPLE://a/b/../b/c/%7a
TB: I'll fix the example since there's an extra
"x/".
RF: RFC doesn't let you make relative path
changes to a relative URI.
TB: I think that if I encounter two URIs that
differ only in scheme case, they are equivalent
per the RFC.
TB: RF, you are saying I can't lose the "../b"?
RF: Servers can do that.
TBL: The absolutizing algo allows this : given
a base URI and an abs URI, you can relative the
abs URI and then combine with a base URI and
regurgitate the abs URI. There are a set of
functions that generate relative URIs that can
then be used to produce abs URIs.: The spec
defines those functions. It should define the
axiom that if you do it and undo it, you get
the same URI.
[TimBL]
Axiom: Abs(Rel(u1, base), base) == u1
[Ian]
TB: 2396 says that the ".." semantics is only
documented in the case of relative URIs. Is
that intentional? Every Web robot on the world
will change "b/../b" into "b"
RF: Or is it the server that does it?
TB: Robot does it.
TBL: What is the desired semantics?
RF: In reality, server can compress these.
Browsers may treat these differently. We don't
want the browser relativizing algorithm on
every URI. Some schemes don't allow
relativization at all.
TBL: But they don't use "slash".
RF: But they might use ".." in the path.
TB, TBL arguing that inapplicability of "../"
in abs path is inconsistent.
RF: What if the server considers these to URIs
to refer to two different resources?
[Zakim]
TimBL, you wanted to point out that just
because we define things to be equivalent does
not mean everyone has to canonicalize
everything
[Stuart]
From RFC2396 Section 4:
The syntax for relative URI is a
shortened form of that for absolute
URI, where some prefix of the URI is
missing and certain path
components ("." and "..") have a special
meaning when, and only when,
interpreting a relative path. The
relative URI syntax is defined in
Section 5.
[Ian]
RF: The standard is defined not in terms of
equiv relationship, but what the browser does.
TBL Proposal: Standard should say that server
must not consider "....b/../b" and "....b/" to
be different.
TB: Implementations do this.
RF: Don't say in the standard that "b/../b" and
"b/" are equivalent. Servers may consider them
to be different.
TB: RF is saying that it's stupid for a server
to treat "b/../b" and "b/" differently, but it
can.
TBL Proposal: Equivalent to say that there's a
canonicalization algo that clients should run.:
Thus, servers can know what to expect.
TB: In fact, that's what clients do: cleanup.
RF: Some concerns about digest authentication.
Servers send redirects back to client [Apache
does this] after canonicalization of URI. We
can try to resolve this problem in 2396. I
suggest we make one URI "good" and the others
"bad cousins"
TBL: That works for me.
[TimBL]
Roy: We could make abs URIs with ../ in illegal
[Ian]
TB: The specific point w.r.t. to the finding: I
think I need to weaken the claim w.r.t. 2396
until we change 2396 or roll this text into
2396.
RF: Or say "in the future..."
[Next]
TB: I think that's it for critical errors.
SW: I'd like clarification of 2396 w.r.t.
escaping.
TB: RFC2396 talks about octet-to-hex encoding,
but not character-to-octet encoding. PC has
raised the issue that popular software libs
user uppercase.
PC: Some private email as well agreeing that
libs do uppercase.
RF: I think that apache uses LC in general but
I'd be happy to change to UC; doesn't matter to
us.
TB: I'll change draft to UC since PC cares and
nobody else seems to.: "Good practice - when
you have to hexify, use UC."
TBL: Fine if this is just good practice (not
required).
Action TB: Do one more draft of URI equiv
draft; then hand off to IJ to make it look like
a finding.
2.3 Architecture document (postponed)
1. Findings in progress:
1. deepLinking-25
1. Action TB 2002/09/09: Revise "Deep
Linking" in light of 9 Sep minutes.
TB: I'll have a revision before the end
of the month.
2. 6 Dec 2002 Editor's Draft of Arch Doc:
1. Next TR page draft?
2. Action CL 2002/09/25: Redraft section 3 based
on resolutions of 18 Nov 2002 ftf meeting.
3. Complete review of TBs proposed principles
CP9, CP10 and CP11
2.3 Priority issues (postponed)
1. IRIEverywhere-27
1. Action MD and CL 2002/11/18: Write up text
about IRIEverywhere-27 for spec writers to
include in their spec.
2. Action CL 2002/11/18: Write up finding for
IRIEverywhere-27 (from TB and TBL, a/b/c), to
include MD's text.
2. binaryXML-30
1. Action CL 2002/12/02: Write up problem
statement about binary XML; send to www-tag.
3. xmlProfiles-29
1. See email from Chris on options for ID
2. See email from NW (TAG-only) on ID
attributes.
3. See comments from Paul Grosso to treat xml:id
as separate spec.
4. Completed action NW 2003/01/06: Write up a
second draft of the TAG position on XML
subsetting based on original proposal.
(Done).
4. namespaceDocument-8
1. Action PC, TB 2003/01/13: Write up a Working
Draft that recommends a data format for
namespace docs (not compulsory) and that such
a document should follow the Rec track
process. The initial content of the document
should be taken from the RDDL challenge
proposals; they are isomorphic in tecnical
content. Please include drawbacks in the
draft.
2. Please read NW summary of the following
proposals:
1. RDDL Proposal from Tim Bray.
2. RDDL Proposal from Chris Wilper
3. RDDL Proposal from TBL
4. RDDL Proposal from Jonathan Borden
5. RDDL Proposal from Micah Dubinko
6. RDDL Proposal from Sandro Hawke
7. See also proposal from Garrett Wilson
5. fragmentInXML-28 : Use of fragment identifiers in
XML.
1. Connection to content negotiation?
2. Connection to opacity of URIs?
_________________________________________________
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/01/21 10:12:30 $
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Tuesday, 21 January 2003 05:14:19 UTC