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

[Minutes] 6 Jan 2003 TAG teleconf (httpRange-14, XInclude conneg, XML next version, namespaceDocument-8)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 06 Jan 2003 22:33:22 -0500
Message-ID: <3E1A4A82.1010906@w3.org>
To: www-tag@w3.org


TAG minutes from the 6 Jan 2003 teleconf available as
HTML [1] and as text below.

  - Ian

[1] http://www.w3.org/2003/01/06-tag-summary.html


    W3C | TAG | Previous: 16 Dec teleconf | Next: 13 Jan
    2003 teleconf

            Agenda for 6 Jan 2003 TAG teleconference

    Nearby: IRC log | Teleconference details ? issues list
    ? www-tag archive

    Note: The Chair does not expect the agenda to change
    after close of business (Boston time) Friday of this

1. Administrative (30min)

     1. Roll call: All present - TBL, SW (Chair), TB, DO,
        PC, NW, RF, CL, DC, IJ (Scribe).
     2. Accepted 16 Dec minutes
     3. Accepted this agenda
     4. Next meeting: 13 Jan 2003. (No regrets)

   1.1 New Year's Resolutions (or what would we like to
   accomplish in 2003?)

    The following are some points suggested by TAG
     1. TB: Finish deepLinking-25 by end of January.
     2. PC: More evangelism of Architecture Principles.
        CL: Once the Arch Doc reaches Rec, this will help
     3. TB: Take Arch Doc to last call by mid-2003. There
        was agreement that further discussion on
        scheduling should be done at the face-to-face
        meeting (after the TAG election closes).

   1.2 Meeting planning

      * Next TAG ftf: 6-7 Feb 2003 in Irvine, CA (USA).
        Regrets: NW. Arriving Thursday afternoon: TB.
        Action IJ: Create meeting page.
      * Call for agenda items.

2. Technical

      * 2.1 httpRange-14
      * 2.2 New issue: XInclude and content negotiation?
      * 2.3 Draft email about next version of XML
      * 2.4 namespaceDocument-8
      * 2.5 Postponed

2.1 httpRange-14

Discussion of the state of the Architecture Document
led into discussion of issue httpRange-14 and
terminology; see below.

See new threads here and here.

        TBL: I find there's a fundamental problem with
        the doc without httpRange-14 resolved. It's
        based on sand since I can't write axioms since
        terms not well-defined. Sandro Hawke has
        started working on text and came to the
        conclusion that the doc is difficult to work
        with with the doc in its current form.
        PC: We need to evangelize the parts we already
        agree to (e.g., interviews, speaking
        CL: I agree that we shouldn't hold up
        low-hanging fruit for thornier issues.
        DC: I would be interested to find out more
        about the food chain of information going to
        webmasters, and get in the loop.
        TB: I want to register my disagreement with TBL
        on the state of the arch doc; I think it is
        useful.: I am willing to invest some more
        effort in httpRange-14, but we are chartered to
        produce a Rec.
        RF: I find the document hard to work with as
        well. It's a compromise between two positions
        that doesn't satisfy either. I think finding
        the way to describe the terminology in a
        precise way is the way forward. We need to
        define the terminology associated with
        resources in a precise and consistent manner. I
        think httpRange-14 is a red herring.
        TBL: httpRange-14 is about whether
        network-available resources are a distinct
        class. There is confusion between "things in
        general" and "Things with information content",
        which makes it difficult.
        RF: I think it's necessary for us to agree to a
        set of terms, otherwise the doc's kind of
        CL: I disagree. Some portions are independent.
        RF: But we need to be able to say what is the
        target of a GET.
        CL: Why can't the HTTP spec say that?
        [Agreement that glossary with well-defined
        terms is important.]

        What are the top 5 terms in the Architecture
        document that TimBL and Roy think need tighter

        IJ: I think ongoing input from all participants
        will be key to getting to last call mid-year.
        RF: I think discussion of last call should wait
        until Feb meeting.: I think we need to write
        down different perspectives on what the
        terminology should be. I think that TimBL and
        my positions will likely converge once written
        down.: Until then, it's in our court to suggest
        changes; TAG should not stop work while we do
        this. Terms come from 5-6 sources; we should
        not invent new terms. There's also descriptive
        text needed to explain what we're talking

        Top 5: Resource, Information Resource (aka
        Document), URI, ...

        RF: Nobody has sent me any text for RFC on

  After other discussion, we continued as follows.

        SW: Should httpRange-14 remain on the
        back-burner or should we give it more
        TB: We have new input from Sandro Hawke.:
        Sandro has also proposed some good language:
        WebArch Ambiguity about Objects, PLUS Suggested
        Major Replacement
        TBL: I had produced a draft with language I
        thought was consistent. That text has been
        dropped. Text that distinguishes documents
        (network available info) from other objects.
        Those who work with Sem Web technology see this
        as a problem.

        where did that edit go? when did timbl do that?

        there's a real issue here: whether the
        architecture recognizes two classes of URIs

        empirically there *are* two classes in
        practical usage

        TBL: It's a problem when you try to build
        systems that model real-world objects.

        But I see no gain & some loss in trying to
        write the difference into the architecture

        TBL: RF has said that this is RDF's problem; I
        feel uncomfortable taking the group there
        again.: Sandro has a different solution:
        Identifiers always refer to documents. You must
        distinguish the case when you are referring to
        an abstract thing behind a document. This is
        the only other consistent model I've seen.
        CL: I heard TBL say we have lots of experience
        with URIs for documents/data. I agree, and I
        also agree that the sem web wants to point to
        things not on the Web. I agree with Sandro that
        the way to do that is to define a new way for
        doing so. One solution is a new URI scheme
        (e.g., "now" - not on the Web) This would
        indicate that the URI is not dereferenceable. I
        think we need a new mechanism to do new things,
        and leave the old one for old things, for which
        it works fine.

        Stuart, pls phrase the question as "is there
        sufficient new information to believe that
        re-opening this issue for discussion would be

        And most importantly that would leave the
        *existing* way of pointing at network stuff

        TB: Sandro has convinced me that I disagree
        with what CL said - defining a URI scheme for
        things not on the Web will not be helpful. It
        seems that the Web arch doesn't need to talk
        about the empirical difference between resource

        If you don't do that then you are saying that
        SW cannot use URI for things not on the web

        TB: Something can be used for naming and
        orthogonally for dereferencing (e.g., namespace
        names). It's a good thing to be able to decide
        later. I still have trouble understanding what
        breaks with this world view.
        RF: If you define a new URI scheme, I can
        create a proxy that GETs representations in
        that URI space.

        the notion that something should be *defined*
        as non-dereferencable seems deeply broken to me

        I accept Roy's proxy argument

        RF: Given the way you can use existing
        applications today, you can't make such
        distinctions within URI space.
        DO: I think we need to be more vigorous when we
        start putting automated resource
        representations at end of URis.


        it's not "at the back of the queue"; it's no
        longer on the queue. We have decided we can
        write the arch doc without it.

        There are some resources which more or less
        *are* their representation, e.g. cute-cat.jpg,
        others clearly not, e.g. XML namespace names.
        Does the architecture care?

        TB: This is being taken up on www-tag (whether
        we want it to be or not). I recommend that TBL
        look at whether there's a way forward there.

2.2 New issue: XInclude and content negotiation

See "Architectural problems of the XInclude CR."

        suggests that this is further evidence that
        XInclude was a mistake

        DC: I would like to see the WG's response
        first; whether commenter is satisfied.

        TimMIT, you wanted to say that the issue is not
        things which are not on the web, its things
        which are not information objects on the web
        (you can't get them by looking them up) but
        ... which you can get information *about* by
        looking them up.
        DanC, you wanted to ask if the WG has responded
        to the XInclude comment yet

2.3 Draft email on what next version of XML might include

  1. xmlProfiles-29
       1. Completed action NW 2002/12/09: Write up a
	 first draft of the TAG position. See NW
	 proposal (TAG-only).

        [DC reads portion of CL's objection.]
        DC: Is XML Base excluded intentionally?
        NW: Yes.
        CL: XML IDs are not a dying thing.
        NW: They are not dying quickly.
        CL: I disagree with NW.

        the way XPointer uses ID should die.

        [Discussion of use of IDs]

        DanC< you queued yourself to say " the way
        XPointer uses ID should die."

        CL: Easier to declare that xml:id is of type
        ID. If you want anything different, then use
        DTDs or other validation mechanisms.

        in fact for virtually all languages invented at
        W3C and elsewhere, foo#bar points to <anything

        CL: I'm not happy having a subset that says you
        can't use DOM and XPointer.: I want to separate
        validation and decoration.: These two concepts
        were conflated in SGML; we could get this right

        CL: There are two separte operations. one is
        the parsing of the input to produce the
        infoset. Another is a validation of the
        document syntax. These were confused in SGML
        and not quite sepraated in XML. This moves
        toward fixing this.

        TB: It's too late for xml:id. Every language
        out there uses "id" to be of type ID.: You
        could adopt James Clark's solution, or you
        could bite the bullet and say that #id means
        the element with the attribute "id"."
        CL: Another way (also proposed by James) is to
        say that xml:id is decoration.
        TBL: Is this an implicit declaration in all

        that's xml:idAttr and you say xml:idAttr="id"

        I'd like to make a "matrix" suggestion. What
        are the solutions that we are talking about,
        and what are there pros/cons?

        Bray referred to the decoration idea as
        "Clark's idattribute" I believe

        CL: Two ways to do this - declare in namespace,
        or do by decoration.: I note that content will
        have to be changed anyway.
        TB: All this aside, I think that NW's
        formulation is correct. We've muddled along and
        it doesn't cause practical problems.
        [CL: It does.]


        TB: The risk of slippery slope for just one new
        feature is horrendous.

        It causes *immense* practical problems
        GetElementByID is the single most used DOM call

        I still assert that the two problems are
        seperable and should be solved separately

        I still assert that they are not orthogonal.
        They are separable, but not totally orthogonal

        DO: I am susceptible to both arguments: no new
        features v. getting ids correct.

        the axes are, like , 70 degrees apart not 90

        your point that they're not orthogonal is well
        made, Chris.

        DO: In Web services, lots of "id" attributes
        being defined over and over (and named "id").

        I agree its well made but TimB does not ...

        DO: I'd like us to keep the door open on this
        particular feature creep.

        I accept that they are not properly orthogonal.
        But they are seperable. The problem exists
        *now* independent of the subset.

        rip the name "id" out of the users' hands I say

        DO: I would love it if CL listed the various
        options for dealing with ids.: I'd like to keep
        the issue open to hear the pros and cons.
        PC: I agree with DO.: I have to keep an open
        mind for other reasons than DO.: I have some
        concerns about wording in NW's proposed text
        about where this work should take place. I
        think we should make clear that the AC will be
        deciding this.
        NW: I hear that, but think we should suggest
        something they should agree on. We can propose
        two different issues.

        a) subsetting XML
        b) xml:id

        NW: I suggest writing up another draft in TAG

        quick straw poll on which list to use?

        TB: I'd rather this take place on www-tag.

        I'm agnostic; light preference for www-tag

        CL, PC: One more round on TAG list would be
        Action NW: Send another draft to tag@w3.org.
        TBL: In an RDF document, there's not a defining
        instance of an id. When something occurs in
        more than one place, it's considered to be the
        same thing.

        TimMIT, you wanted to note that graph-oriented
        systems can't use xml's id because there is no
        distinction between definition and use. XML
        makes the assumption that one occrrence of
        ... the id is special.

        TB: Why can't you have a new spec that defines
        a subset?
        NW: You could, but if you had a combined
        document that only defined a subset, then I
        think the people still using DTDs would be
        cheated out of that useful body of work. And
        that two parallel things going forward would be
        [Discussion about number of specs.]
        TB: I disagree that if you do "grand
        unification" you would also have to do "all of
        CL: There's another way to do this - define a
        small version, and base 1.1 on that.
        NW: That's what I had in mind.
        CL: You include the subset by reference (in the
        1.1 draft).
        NW: The two points I want to make are (1) I
        think that will be a lot of work and (2) I
        would be uncomfortable *not* doing it.

        Sounds as though we have 3 useful tasks. 1)
        subsetting 2) xml:ids 3) unification of specs
        without changing anything else

        TB: I am not comfortable with "MUST do all of
        1.1." I am fine with two statements (1) big job
        and (2) might be problematic if only include

2.4 namespaceDocument-8

  1. namespaceDocument-8
       1. Completed action NW 2002/11/18: Take a stab
	 at indicating pros and cons for the various
	 RDDL/RDF/Xlink designs arising from TB's RDDL
	 challenge. See NW summary of 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

        NW: They're all adequate. Just pick one. I
        picked Jonathan's proposal.
        RF: WHy do we need to pick one?
        PC: What's http content negotiation all about?:
        Why aren't image formats similar?
        TBL: You need dominant image formats.

        (i.e.. let the market decide which one

        PC: I am not sure that having a single format
        is the right answer.

        I am increasingly convinced that a single
        format is desirable

        I am increasingly convinced that I don't know
        which is better.

        TB: We can't say "you MUST use X" but it would
        be a benefit to the community to bless one
        format. Also, check out Sandro's suggestion....

        Conneg and separate URIs are not exclusive! You
        can do both.

        Big general discsuusion, old one, pros and

        TBray, you wanted to say I now like Sandro's

2.5 Postponed

  1. Status of URIEquivalence-15, IRIEverywhere-27.
     Relation to Character Model of the Web (chapter
     4)? See text from TimBL on URI canonicalization
     and email from Martin in particular. See more
     comments from Martin.
       1. Action MD 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.
	 CL: No progress. Update expected 13 Jan.
  2. binaryXML-30
       1. Action CL 2002/12/02: Write up problem
	 statement about binary XML; send to www-tag.
  3. xlinkScope-23 (5 minutes)
       1. Action SW 2002/11/18: Organize a
	 special-interest teleconf for discussion of
	 this issue on linking. Pending; see email
	 from SW (TAG-only).
       2. Completed action SW 2002/12/09: Contact the
	 Hypertext Coordination group, Vincent Quint
	 chair, as part of organizing linking meeting.
  4. fragmentInXML-28 : Use of fragment identifiers in

2.6 Findings in progress, architecture document

See also: findings.
  1. Findings in progress:
       1. deepLinking-25
	   1. Action TB 2002/09/09: Revise "Deep
	      Linking" in light of 9 Sep minutes.
       2. URIEquivalence-15
	   1. TB's "How to Compare Uniform Resource
	      Identifiers" draft finding.
	      TB: I expect to have this done by end of
	      DC: I expect to review this.
	      PC: More time required since there are
	      Microsoft engineers looking at this.
  2. 6 Dec 2002 Editor's Draft of Arch Doc (new):
       1. Action CL 2002/09/25: Redraft section 3 based
	 on resolutions of 18 Nov 2002 ftf meeting.
       2. Complete review of TBs proposed principles
	 CP9, CP10 and CP11

  Stuart Williams for TimBL
  Last modified: $Date: 2003/01/07 03:25:55 $

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Monday, 6 January 2003 22:33:25 UTC

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