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

Minutes of 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 week.

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 participants:

  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 deployment.

  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

2. Technical

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.

[Ian]
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 opportunities).
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 pointless.
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.]
[PaulC]
What are the top 5 terms in the Architecture document that TimBL and Roy think need tighter definitions?
[Ian]
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 about.
[timMIT]
Top 5: Resource, Information Resource (aka Document), URI, ...
[Ian]
RF: Nobody has sent me any text for RFC on URIs.

After other discussion, we continued as follows.

[Ian]
SW: Should httpRange-14 remain on the back-burner or should we give it more attention?
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.
[DanC]
where did that edit go? when did timbl do that?
[TBray]
there's a real issue here: whether the architecture recognizes two classes of URIs
[TBray]
empirically there *are* two classes in practical usage
[Ian]
TBL: It's a problem when you try to build systems that model real-world objects.
[TBray]
But I see no gain & some loss in trying to write the difference into the architecture
[Ian]
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.
[DanC]
Stuart, pls phrase the question as "is there sufficient new information to believe that re-opening this issue for discussion would be worthwhile?"
[Chris]
And most importantly that would leave the *existing* way of pointing at network stuff alone
[Ian]
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 classes.
[Chris]
If you don't do that then you are saying that SW cannot use URI for things not on the web
[Ian]
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.
[TBray]
the notion that something should be *defined* as non-dereferencable seems deeply broken to me
[Chris]
I accept Roy's proxy argument
[Ian]
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.
[Roy]
punt
[DanC]
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.
[TBray]
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?
[Ian]
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."

[TBray]
suggests that this is further evidence that XInclude was a mistake
[Ian]
DC: I would like to see the WG's response first; whether commenter is satisfied.
[Zakim]
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 (xmlProfiles-29)

  1. xmlProfiles-29
    1. Completed action NW 2002/12/09: Write up a first draft of the TAG position. See NW proposal (TAG-only).
[Ian]
[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.
[DanC]
the way XPointer uses ID should die.
[Ian]
[Discussion of use of IDs]
[timMIT]
DanC< you queued yourself to say " the way XPointer uses ID should die."
[Ian]
CL: Easier to declare that xml:id is of type ID. If you want anything different, then use DTDs or other validation mechanisms.
[TBray]
in fact for virtually all languages invented at W3C and elsewhere, foo#bar points to <anything id="bar">
[Ian]
CL: I'm not happy having a subset that says you can't use DOM and XPointer.: I want to separate validation and declaration.: These two concepts were conflated in SGML; we could get this right now.
[timMIT]
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.
[Ian]
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 declaration.
TBL: Is this an implicit declaration in all documents?
[TBray]
that's xml:idAttr and you say xml:idAttr="id"
[DaveO]
I'd like to make a "matrix" suggestion. What are the solutions that we are talking about, and what are there pros/cons?
[DanC]
Bray referred to the declaration idea as "Clark's idattribute" I believe
[Ian]
CL: Two ways to do this - declare in namespace, or do by declaration.: 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.]
[Chris]
Grrrrrrr
[Ian]
TB: The risk of slippery slope for just one new feature is horrendous.
[Chris]
It causes *immense* practical problems
GetElementByID is the single most used DOM call
[Norm]
I still assert that the two problems are seperable and should be solved separately
[Chris]
I still assert that they are not orthogonal. They are separable, but not totally orthogonal
[Ian]
DO: I am susceptible to both arguments: no new features v. getting ids correct.
[Chris]
the axes are, like , 70 degrees apart not 90
[DanC]
your point that they're not orthogonal is well made, Chris.
[Ian]
DO: In Web services, lots of "id" attributes being defined over and over (and named "id").
[Chris]
I agree its well made but TimB does not ...
[Ian]
DO: I'd like us to keep the door open on this particular feature creep.
[Norm]
I accept that they are not properly orthogonal. But they are seperable. The problem exists *now* independent of the subset.
[TBray]
rip the name "id" out of the users' hands I say
[Ian]
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.
[Chris]
a) subsetting XML
b) xml:id
[Ian]
NW: I suggest writing up another draft in TAG space.
[DanC]
quick straw poll on which list to use?
[Ian]
TB: I'd rather this take place on www-tag.
[DanC]
I'm agnostic; light preference for www-tag
[Ian]
CL, PC: One more round on TAG list would be better.
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.
[Zakim]
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.
[Ian]
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 confusing.
[Discussion about number of specs.]
TB: I disagree that if you do "grand unification" you would also have to do "all of 1.1".
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.
[timMIT]
Sounds as though we have 3 useful tasks. 1) subsetting 2) xml:ids 3) unification of specs without changing anything else
[Ian]
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 subset.

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
[Ian]
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.
[Roy]
(i.e.. let the market decide which one dominates)
[Ian]
PC: I am not sure that having a single format is the right answer.
[TBray]
I am increasingly convinced that a single format is desirable
[Roy]
I am increasingly convinced that I don't know which is better.
[Ian]
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....
[DanC]
Conneg and separate URIs are not exclusive! You can do both.
[timMIT]
Big general discsuusion, old one, pros and cons.
[Zakim]
TBray, you wanted to say I now like Sandro's proposal

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 XML.

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 January.

        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/13 20:08:36 $