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

  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


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)

  1. xlinkScope-23
    1. Summary of 16 Jan special teleconference (TAG-only).


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.
is that "can't live without it" requirement about mutiple links on one element a matter of record?
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.
I'd certainly sign up for the improvements TBray describes on XLink
[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.


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.
TB: I think all specs in this space that are relevant are RFCs, but I'll check.
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.
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.
Axiom: Abs(Rel(u1, base), base) == u1
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?
TimBL, you wanted to point out that just because we define things to be equivalent does not mean everyone has to canonicalize everything
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.
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.
Roy: We could make abs URIs with ../ in illegal
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..."
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/23 07:11:06 $