[Minutes] 20 Jan 2003 TAG teleconf (xlinkScope-23, Comparing URIs)


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


           SW: I intend to call people to help flesh out
           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


           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

           PC: Will summary be available?
           IJ: I produced one; mostly derived from IRC
           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
           TB: There are responses from Misha, Chris, TB
           on this. [And IJ recalls comments from TBL as
           [Attributes on attributes was mentioned]
           RF: Can we include some of this in the arch
           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
           NW, TB: Good idea to talk about this in arch
           PC: What about list attributes (e.g., class in
           TB: List of attribute values is more work for
           SW: I have mixed feelings about "doing nothing"
           at this point. What about producing a finding
           (even if it just articulates an opinion already
           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:
           PC: We meet this week to discuss the agenda. It
           was suggested that we not go into linking
           SW: Liam may organize a BOF.
           PC: I'd like us to have a firm bring forward
           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

           I'd certainly sign up for the improvements
           TBray describes on XLink

           [SW summarizes for TBL, who just arrived in
           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
           TBL: I think this is the time to do it. RF, do
           you need help. Please, please, please make this
           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

           TB: I'll fix the example since there's an extra
           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.

           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

           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
           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
           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.
           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
           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
           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
          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.
     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
          2. Please read NW summary of the following
               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
          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