W3C home > Mailing lists > Public > www-tag@w3.org > April 2003

[Minutes] 14 Apr 2003 TAG teleconf (URIEquivalence-15, IRIEverywhere-27, xmlIDSemantics-32, abstractComponentRefs-37, namespaceDocument-8)

From: Ian B. Jacobs <ij@w3.org>
Date: 15 Apr 2003 11:51:05 -0400
To: www-tag@w3.org
Message-Id: <1050421865.10814.151.camel@seabright>


The minutes of the 14 Apr 2003 TAG teleconf are
available as HTML [1] and as text below.

 - Ian

[1] http://www.w3.org/2003/04/14-tag-summary.html


                   Minutes of 14 Apr 2003 TAG teleconference

1. Administrative

    1. Roll call: SW (Chair), TBL, PC, DO, TB, CL, NW, RF, IJ (Scribe),
       Martin Duerst (for IRI discussion). Regrets: DC
    2. Accepted [7]7 Apr teleconference minutes
    3. Accepted this [8]agenda
    4. Next meeting: 28 April. Regrets IJ.

      [7] http://www.w3.org/2003/04/07-tag-summary.html
      [8] http://www.w3.org/2003/04/14-tag.html

  1.1 Meeting planning

     * Please register for AC meeting and WWW2003 if you are a speaker.
     * The TAG will strive to organize a virtual meeting shortly after
       the WWW Conference. See [9]thoughts from SW on organizing a
       virtual meeting. See [10]questionnaire
     * Resolved: TAG will try to have distributed mtgs on 2 and 19 June;
       no meeting 16 June.
       SW: One possibility is a 4-hour meeting. Video? Shared white
       TB: I've used a shared white board; useful.
       Action SW: Propose meeting times, structure to TAG.
       TB: I'd be willing to start early for such a meeting (e.g., 7am ok
       by me)
       DO: I may not be there that early...

      [9] http://lists.w3.org/Archives/Member/tag/2003Mar/0082.html
     [10] http://www.w3.org/2002/09/wbs/34270/05%252F06.03/

  1.2 W3C Track Presentation

     * [11]W3C track
     * [12]Notes from Paul Cotton.

     [11] http://www2003.org/t_www.htm
     [12] http://lists.w3.org/Archives/Member/tag/2003Apr/0010.html


          PC suggestion:

          + scope and role of the TAG
          + sample findings issued by the TAG and their results
          + overview of the Web Architecture document

          PC: I spoke with Janet about this; she thought it was
          reasonable to assume that there would be a number of people in
          this audience who would not be familiar with the TAG. Intro
          talk touching on some technical details appropriate.
          SW: Do we have the material?
          PC: I think so.
          SW: One presenter or more?
          PC: One or two; I volunteer to be one.
          Who will attend: PC, CL, IJ, TBL, DC (don't know).
          Who will not: SW, TB, RF, DO, NW
          PC: I'll start the presentation and we can decide later who
          will give it.
          Action PC: Prepare W3C track presentation.
          SW: We should discuss 28 April.
          PC: Slides may not be available until slightly after...

  1.3 TAG report at AC meeting

    1. Completed action IJ 2003/04/07: Report to mtg organizer TBL
       constraint on slot for TAG report, then report back to TAG on
       revised slot (11:30-12:30).
    2. [13]Suggestions for TAG presentation at May AC Meeting from DO and

     [13] http://lists.w3.org/Archives/Member/tag/2003Apr/0027.html


          SW: I heard a proposal to state our plans for last call of arch
          doc. Not sure we've closed that....
          DO: Two questions to ask of AC:

         1. Faster arch doc or more complete?
         2. Shape of arch doc

          PC: Idea is that we wanted to be sure that we had some
          questions for the AC. Need to decide who will give
          SW: Slot is 11:30-12:30
          Resolved: DO and CL will present TAG report at AC meeting.

  1.4 Completed action items

    1. Action IJ 2003/04/07: Send out [14]summary of TAG activity.

     [14] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0036.html

2. Technical

    1. [15]URIEquivalence-15
    2. [16]IRIEverywhere-27
    3. [17]xmlIDSemantics-32
    4. [18]abstractComponentRefs-37
    5. [19]namespaceDocument-8


          IJ: I am revising get7 finding; hope to have draft for TAG to
          review in the next day or so.

  2.1 URIEquivalence-15

     * [20]URIEquivalence-15
          + SW proposal: Track RFC2396bis where [21]Tim Bray text has
            been integrated. Comment within the IETF process. Move this
            issue to pending state.

     [20] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
     [21] http://www.textuality.com/tag/uri-comp-4

          SW: RF has incorporated into RFC2396bis. My proposal is to let
          that text evolve through IETF process.
          TB: SW posted some notes to uri@w3.org in this spirit.
          RF: Seems reasonable to proceed thusly.
          Resolved: Move URIEquivalence-15 to "Pending"

  2.2 IRIEverywhere-27

   Martin Duerst joins the call
     * [22]IRIEverywhere-27
          + Action CL 2003/04/07: Revised position statement on use of
            IRIs. CL says to expect this by 21 April.
          + What text can we advise WGs to include in their specs on the
            use of IRIs?

     [22] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27

          SW: Where are we on this?

          Tim, which document?

          TBL: Rules in TB's[23]uri-comp-4 ("6. Good Practice When
          Generating URIs"). Is assumption for IRIs that someone will do
          mapping from 8 to 7 bit?
          CL: Yes.
          TBL: If so, there will be an increasing gulf between namespace
          approach and others.

     [23] http://www.textuality.com/tag/uri-comp-4

          q+ to say that this is the compare vs dereference thing al over

          TBL: Are we prepared to live with this anomaly?
          CL: the spec says that if you are using 7-bit transport, you do
          the mapping, and you do it as late as possible.
          TBL: But all the time, because you can do the mapping, they
          will identify the same thing. At any time you can do the
          mapping, so anyone who does the mapping is valid.

          "generating" vs "processing" ?

          MD: TB's text is good practice for those generating URIs.

          Chris, you wanted to say that this is the compare vs
          dereference thing al over again

          TB: I'm kind of struggling here... Can we agree on the issues

         1. What help can we give the community (of spec writers) on the
            usage of IRIs? (especially since docs are in motion)
         2. There are some problems with IRIs themselves; TAG can provide
            useful input to IRI spec process.

          TBL: I think there is a concisely statable problem: Our finding
          draws attention to the way of canonicalizing URIs, thereby
          indicating that canonicalization is a reasonable thing to do.
          We say "beware; don't expect people to do it".

          I propose that we formally say: "The TAG feels that IRIs are a
          good thing, and people writing specs with places for
          identifiers bear this in mind, but
          the IRI spec is still in motion and that's a fact of life, so
          we're not going to write interim text for anyone, sorry."

          TBL: But is the TAG licensing canonicalization?
          CL: I have moved away from my position due to practical
          considerations; I think that if we ask people to canonicalize,
          they won't do it
          TBL: I heard DC saying we should eliminate hex-encoding and
          just move to UTF-8 strings.
          CL: This breaks implementations of XSLT and namespace
          TBL: But they don't notice it today since they don't use IRIs
          CL: That turns out not to be true. One case is
          uppercase/lowercase hex encoding. You have to tell them that
          uppercase and lowercase hex have to compare the same in all
          cases, and currently they don't. The canonicalization algo will
          thus bite them even if they are not doing IRIs.
          TBL: With URIs we don't expect people to mix case when using
          URis; with IRIs we do expect people to use Kanji characters.
          I think there is an unresolved issue inherent in Chris' respone
          - the fact that RFC2396-Sensitive Comparison is licensed by the
          TAG finding, so we should really move everyone up to using
          canon'n algorithm.

         1. I think we have consensus on the following: "In the future,
            good to use IRIs (no hex-encoding)"
         2. The IRI spec is not done (That's part of life).
         3. The TAG shouldn't write an interim spec.
         4. The way Schema 1.0 handled this was reasonable.

          q+ to ask whether we are eally clear that the last part - is
          canonicalization allowed in *proceessing* URIs?

          The way XML 1.0 not xml schema handled it

          TBL: I agree with good practice points (canonicalize URIs). But
          "IRIs are a good thing" is not enough. To say that "IRIs are
          separate from URIs" I think that that would break a lot of Web
          software. My assumption is that we've been licensing the

          q+ to ask tim what in particular these 7-bit fields are

          I propose we close this issue by issuing a one-word statement:

          TBL: IRIs are also impacted by the URI equivalence comparison
          issue since UTF-8 is involved. In the case of IRIs, there's a
          serious need to use both 7 and 8 bit.

          current IRI spec says use upper case if you have to use

          TBL: The equivalence issue shines a brighter light on the IRI

          tim-mit, you wanted to ask whether we are eally cleat that the
          last part - is canonicalization allowed in proceessing URIs?
          and to ask whether we are eally clear that the last part
          ... - is canonicalization allowed in *proceessing* URIs?

          TBL: I want to use TB's document for IRIs as well. If we adopt
          this document for URIs, seems like we should do so for IRIs as

          MJDuerst, you wanted to ask tim what in particular these 7-bit
          fields are

          TB: I think we should close 27 with a one-word statement: Yes.

          q+ to conclude: When everyone uses URIs, Simple String
          Comparson works pretty well, but our answers to issues 15 & a7
          are incompatible.

          TB: Should we take up another IRI issue, or address that in the
          I18N forum?
          CL: I think that "Yes" is insufficient as an answer to 27; they
          asked "how"
          RF: Until IRI is not a moving target, it should not be
          recommended by any spec. Recommend CDATA if you want; don't
          point to specs in development.

          tim-mit, you wanted to conclude: When everyone uses URIs,
          Simple String Comparson works pretty well, but our answers to
          issues 15 & a7 are incompatible.

          TBL: While I agree with RF formally, people are looking for a
          little bit of vision to the other side of the desert. I think
          we cannot treat these two issues independently; the answers to
          issues 15 and 27 are incompatible. In issue 15 we solve the
          problems by suggesting canonicalization (into a more standard
          7-bit notation). In 27, we suggest moving away from a std 7-bit
          notation to either (1) a complete 8-bit world or a (2) 8-bit
          world with a direct mapping to a 7-bit world but you are not
          persuaded to move in one direction or the other.

          16 = transmitter makes right. 27 - receiver makes right

          MD: TBL said a lot of 7-bit fields might suffer from moving to
          8 bit. Which ones? For namespaces and for RDF I don't see any
          problem (since both occur in 8-bit specs).
          TBL: HTTP, SMTP will break.
          MD: That's retrieval.
          TBL: HTTP headers send around URIs (related to email, news,
          etc.) quoting the URI spec.
          MD: We are explicitly not proposing that HTTP suddenly use 8
          TBL: What happens when someone types in an 8 bit IRI and it has
          to be sent in 7 bit HTTP?
          MD: IRI spec licenses canonicalization.
          TBL: Voila.
          MD: For retrieval.
          TBL: We may not be retrieving! We may just be talking about it
          in an email message.
          MD: My general view is that SMTP is broken in that respect
          anyway... You can send xml in email (base 64 encoding)
          CL: You can do that or use numeric char references in your URI.

          xml allows you to use ncr - what s the issue here?

          SW: How do we help move IRI spec along? In TB finding, he talks
          about codepoint-by-codepoint comparision; this also seems
          relevant to the 8-bit/7-bit discussion. [It's fine to do
          codepoint-by-codepoint comparison]
          MD: The IRI spec doesn't define canonicalization for the
          TBL: But it defines a mapping from IRIs to URIs. That's a form
          of canonicalization....
          CL: We are saying that it's not; we are saying it's a
          conversion. We are not implying that the URI is in a canonical
          TBL: But it is a canonicalization algo in the sense that it
          maps a string to a subset of IRIs (namely URIs).

          q+ to say that there is software, APIs, net protocols, and so
          on which take URIs as a 7-bit value. You can't, and the IRI
          draft doesn't suggest you just squeeze 8 bits into the 7bit

          MD: IRI spec says explicitly "You don't do this unless you have

          I'll be in Japan next week, and traveling the week after,

          TBL: I think that, for this to hold together, we'll need a
          finding ( iri-comp-4...) which extends the URI Equivalence text
          to talk about IRIs. We need to explicitly answer the question:
          "If I have an IRI, can I turn into a 7-bit form if I'm an
          intermediary?" I think that we'll have to modify our response
          to 15 when we look at 27.

          q+ to say that if you want IRI to move forward, this discussion
          better get somewhere soon.

          SW: Should this be going on in TAG or in I18N + URI Activities?

          tim-mit, you wanted to say that there is software, APIs, net
          protocols, and so on which take URIs as a 7-bit value. You
          can't, and the IRI draft doesn't suggest you just squeeze 8
          ... bits into the 7bit space.
          MJDuerst, you wanted to say that if you want IRI to move
          forward, this discussion better get somewhere soon.

          MD: If this discussion continues the way it has over the past
          few weeks, the IRI spec will not move forward. I can, of
          course, just pick a way forward...but I don't want to do that.
          RF: This discussion does not have an impact on the content of
          the IRI spec.
          MD: My understanding is that what TBL wants to do is not
          independent of the IRI spec.
          RF: If you were to publish the IRI spec tomorrow, then the
          issue we are talking about is answered. The only thing that's
          missing today is a reference for the IRI spec.
          TBL: I think we are being asked to look at the bigger picture
          (usage of IRIs).
          CL: Yes, I agree with TBL.
          TB: I think that we can tell the community that in specs, in
          slots where ids can go, do not constraint to just what's
          blessed by RFC2396. It's ok to have non-ascii chars in formats
          and protocols.

          Is a processor allowed to canonicalize an IRI using the IRI

          TB: Not sure what else to say. Perhaps (1) keep an eye on IRI
          work; we support it (2) we recommend canonicalizatoin and it
          applies to URIs and IRIs. Most importantly, canonicalization on
          generation is best.
          TBL: So you should display a Kanji char and immediately convert
          to 7 bit?
          MD: The question is whether TB's good practice for URIs applies
          literally to IRIs or "appropriately" to IRIs.

          Martin would like to NOT canonicalize early (on generation) but
          to have such a well-defined equivalence that one can delay the
          canonicalization to any time. This is the opposite of the style
          of uri-comp-4.
          hence the connection between 15 and 27

          MD: There are thus two ways to do this, and possibly other ways
          in between. You can apply section 6 of uri-comp-4 in a literal
          sense (# Only perform %-escaping where required by RFC2396.) or
          in an appropriate spec (# Only perform %-escaping where
          required by IRI spec)
          TB, MD: I'd prefer to do the latter.

          What do we think about the way Namespace 1.1 handles this?

          TBL: We can't get away with string compare for IRIs. We want
          people for people to be able to exchange 7-bit and 8-bit forms.
          CL: If you want to make something 7-bit, don't use hex
          conversion; use numeric char references.: Since we are talking
          about XML Namespaces here.
          TBL: I'm also imagining other contexts (e.g., email headers)
          SW: How to move forward?
          TB: MD's comments after last week's meeting were helpful (even
          if I disagreed with some of them).
          MD: I think I'll take Roy's advice and just do something...
          TB: I think we can say - (1) virtue of early canonicalization
          (2) IRIs good; keep an eye on them (3) support 8-bit
          identifiers, even if IRI spec not done. Canonicalization:
          "Don't use "/../". Avoid other crap, independent of Kanji or
          Action TB: Draft a proposed step forward on IRI 27.
          CL: My action may be moot depending on TB's results: "Action CL
          2003/04/07: Revised position statement on use of IRIs. CL says
          to expect this by 21 April."

  2.3 xmlIDSemantics-32

     * [24]xmlIDSemantics-32
          + See [25]Chris Lilley draft finding

     [24] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
     [25] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html

          * See Chris Lilley draft finding

          good bye everybody. thanks for having me here.

          Proposed: Send "How should the problem of identifying ID
          semantics in XML languages be addressed in the absence of a
          DTD?" to www-tag for their consideration?
          CL: This is mostly discussion; no conclusion. Almost all of the
          material is on the email thread.


          Resolved: Make "Chris Lilley draft finding" public.
          Abstain: TBL

          Needs more discussion. No conclusion yet. This document is a
          summary made available by the TAG; it is hoped that it lists
          all the solutions that have been proposed, and their advantages
          and disadvantages, which should help any group chartered to
          deal with this problem. The TAG is unhappy with the current
          situation and would like to see further discussion and
          convergence on a solution.

          Action SW, NW: Read Client handling of MIME headers. If +2,
          then IJ will send to www-tag.
          Resolved: That approach for deciding to make public finding is

  2.4 abstractComponentRefs-37

     * [26]abstractComponentRefs-37

     [26] http://www.w3.org/2003/04/24-tag-summary.html#abstractComponentRefs-37

          DO: 11 different options in [27]latest summary. I didn't get
          much comment on tag@w3.org; got more feedback on www-tag.
          PC: Please either post to www-tag or give us 7 days.
          DO: Lurking here is an issue about URIs/URNs....

     [27] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html

  2.5 namespaceDocument-8

     * [28]namespaceDocument-8
          + Action TB 2003/04/07: Prepare RDDL Note. Include in status
            section that there is TAG consensus that RDDL is a suitable
            format for representations of an XML namespace. Clean up
            messy section 4 of RDDL draft and investigate and publish a
            canonical mapping to RDF.
          + Action PC 2003/04/07: Prepare finding to answer this issue,
            pointing to the RDDL Note.

     [28] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8

          PC: In [29]TB's 16 theses, he includes "don't use URNs"; I'm
          not sure that the TAG has taken a position on that point.
          SW: I think we said it was important that namespace doc be both
          human- and machine-readable.
          TB: Jonathan is working on the RDDL part.
          PC: There's a US Govt namespace recommendatoin that proposes to
          use URNs instead of URLs. {Draft policy}

     [29] http://www.textuality.com/tag/Issue8.html

  2.7 Architecture document

   See also: [30]findings.
    1. [31]26 Mar 2003 Working Draft of Arch Doc:
         1. Action DC 2003/02/06: Attempt a redrafting of 1st para under
            [32]2.2.4 of 6 Feb 2003 draft
         2. Action DC 2003/01/27: write two pages on correct and
            incorrect application of REST to an actual web page design
         3. Action DO 2003/01/27: Please send writings regarding Web
            services to tag@w3.org. DO grants DC license to cut and paste
            and put into DC writing.
         4. Action DC 2003/03/17: : Write some text for interactions
            chapter of arch doc related to [33]message passing, a dual of
            shared state.

     [30] http://www.w3.org/2001/tag/findings
     [31] http://www.w3.org/TR/2003/WD-webarch-20030326/
     [32] http://www.w3.org/2001/tag/2002/webarch-20030206#uri-use
     [33] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html

  2.8 Issues that have associated action items

     * [34]contentTypeOverride-24
          + Solicit review of [35]draft finding from IJ?
     * [36]xlinkScope-23
          + Status report?
          + See [37]draft, and [38]SW message to CG chairs.
     * [39]siteData-36
          + Action TBL 2003/02/24 : Summarize siteData-36
     * [40]xmlFunctions-34
          + Action TBL 2003/02/06: State the issue with a reference to
            XML Core work. See [41]email from TimBL capturing some of the
     * [42]binaryXML-30
          + Action TB 2003/02/17: Write to www-tag with his thoughts on
            adding to survey.
          + Next steps to finding? See [43]summary from Chris.
     * [44]contentPresentation-26
          + Action CL 2003/02/06: Create a draft finding in this space.
            Deadline 3 March.
     * [45]rdfmsQnameUriMapping-6
          + Action DC 2003/02/06: Propose TAG response to XML Schema
            desideratum ([46]RQ-23).
     * [47]uriMediaType-9
          + Action DC 2003/02/06: Start discussion on
            discuss@apps.ietf.org, but not urgent
     * [48]HTTPSubstrate-16
          + Action RF 2003/02/06: Write a response to IESG asking whether
            the Web services example in the SOAP 1.2 primer is intended
            to be excluded from RFC 3205
          + See [49]message from Larry Masinter w.r.t. Web services.
     * [50]errorHandling-20
          + Action CL 2003/02/06: Write a draft finding on the topic of
            (1) early/late detection of errors (2) late/early binding (3)
            robustness (4) definition of errors (5) recovery once error
            has been signaled. Deadline first week of March.
     * [51]metadataInURI-31
          + Action SW 2003/02/06: Draft finding for this one.
     * [52]fragmentInXML-28 : Use of fragment identifiers in XML.
         1. Connection to content negotiation?
         2. Connection to opacity of URIs?
         3. No actions associated / no owner.

     [34] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
     [35] http://www.w3.org/2001/tag/doc/mime-respect-20030405.html
     [36] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
     [37] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
     [38] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
     [39] http://www.w3.org/2001/tag/ilist.html#siteData-36
     [40] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
     [41] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
     [42] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
     [43] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
     [44] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [45] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
     [46] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
     [47] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
     [48] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
     [49] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
     [50] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
     [51] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [52] http://www.w3.org/2001/tag/ilist#fragmentInXML-28

3. Other actions

     * Action IJ 2003/02/06: Modify issues list to show that
       actions/pending are orthogonal to decisions. IJ is working with
       PLH on this. Revisit this end of April.


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2003/04/15 15:49:26 $

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Tuesday, 15 April 2003 11:51:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:58 UTC