W3C | TAG | Previous: 13 Jan teleconf | Next: 27 Jan 2003 teleconf
Minutes of 20 Jan 2003 TAG teleconference
Nearby: IRC log | Teleconference details · issues list · www-tag archive
1. Administrative
- Roll call: SW (Chair), NW, PC, DC, RF, IJ, TB, DO, TBL. Regrets:
CL.
- Accepted 13 Jan minutes
- Accepted this agenda
- 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
- xlinkScope-23
- 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:
- 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.
- 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
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 an absolute
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)
- Findings in progress:
- deepLinking-25
- 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.
- 6 Dec 2002 Editor's Draft of
Arch Doc:
- Next TR page draft?
- Action CL 2002/09/25: Redraft section 3 based on resolutions of 18 Nov 2002 ftf
meeting.
- Complete review of TBs proposed
principles CP9, CP10 and CP11
2.3 Priority issues (postponed)
- IRIEverywhere-27
- Action MD and CL 2002/11/18: Write up text about IRIEverywhere-27
for spec writers to include in their spec.
- Action CL 2002/11/18: Write up finding for IRIEverywhere-27 (from
TB and TBL, a/b/c), to include MD's text.
- binaryXML-30
- Action CL 2002/12/02: Write up problem statement about binary XML;
send to www-tag.
- xmlProfiles-29
- See email from Chris on options
for ID
- See email from NW (TAG-only) on ID
attributes.
- See comments
from Paul Grosso to treat xml:id as separate spec.
- Completed action NW 2003/01/06: Write up a second draft of the TAG
position on XML subsetting based on original
proposal. (Done).
- namespaceDocument-8
- 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.
- Please read NW
summary of the following proposals:
- RDDL
Proposal from Tim Bray.
- RDDL
Proposal from Chris Wilper
- RDDL Proposal from
TBL
- RDDL
Proposal from Jonathan Borden
- RDDL
Proposal from Micah Dubinko
- RDDL
Proposal from Sandro Hawke
- See also proposal
from Garrett Wilson
- fragmentInXML-28
: Use of fragment identifiers in XML.
- Connection to content negotiation?
- Connection to opacity of URIs?
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/01/23 07:11:06 $