W3C | TAG | Previous: 3 Nov teleconference | Next: 15-17 Nov TAG ftf meeting

Minutes of 10 November 2003 TAG teleconference

Nearby: IRC | Teleconference details issues list (handling new issues) www-tag archive

1. Administrative (15min)

  1. Roll call: SW (Chair), TBL, DO, NW, DC, PC, TB, RF, IJ (Scribe). Regrets: CL
  2. Accepted the minutes of the 27 Oct teleconference

    Completed action IJ: Ping DO and PC for help filling in the blanks.

  3. The TAG did not accept the minutes of the 3 Nov teleconference
    DO: I will look them over over the next few days.
  4. Accepted this agenda
  5. Next meeting: 15-17 Nov 2003 TAG ftf meeting in Japan

1.1 TAG ftf meeting at Tech Plenary?


  1. The TAG will meet face-to-face on Tues 5 Mar, during the Tech Plenary week.
  2. The TAG will try to liaise with at least the following groups during that week (including Tuesday): HTML, I18N, WSDL, XML Schema.
  3. New and current TAG participants will be invited to attend.

Action SW: Follow up on TAG ftf meeting with Tech Plenary organizers and with Chairs of other groups to determine their availability..

Action SW/PC: Explore possibility of TAG videolink TAG distributed meeting in February.

1.2 TAG Nov face-to-face meeting agenda

  1. Meeting and agenda page
  2. Agenda outline:
    1. Review of Architecture Document. 12 November version?
    2. Last call decision, timetable, plan.
    3. Breakout sessions to address must do items.
    4. deepLinking-25
      1. Completed action IJ 2003/11/03: Invite Janet to TAG's ftf meeting in Japan.
    5. Other issues...


SW: My proposal was to have people send written reviews of the arch doc.
DC: I can't read anything new between now and meeting.
IJ: I was planning to have next editor's draft tomorrow, based 27 Oct 2003 Editor's Draft.
DC: That will be counter-productive for my purposes. Stuart, please get endorsement for the document before you ask for objections.

Expect to do a review of the (upcoming) 11 Nov draft: RF, NW, TBL

Trouble is, I was going to edit slides on the plane.
DC: Re ftf agenda and last call decision: I think it would be great to say at the meeting "Yes, this doc is ready for last call." I think that we are likely to make more edits.
TBray: I'd like to have a TAG decision on the substance of my request.
DO: I can agree to no more major structural changes, but not to point on new material (since NW and I have been working on extensibility and versioning material).
NW: I am unhappy with the current extensibility section and would like it fixed.
TBray: I think that abstractcomponentrefs is not cooked enough to be in the arch doc.
grumble. I did my action item to create material in abstractcomponentrefs for inclusion in the web arch....
yeah, but it's a way harder issue.
IJ: I don't have need to make big structural changes; I suspect TAG may want to at FTF meeting.
NW: My comment was that nobody on the TAG should make substantial changes except for versinoing sectino.
PC: I think the TAG needs to be date-driven.
+1 to Norm's formulation
IJ: I would like to walk through my announced intentions before I make a complete commitment.
PC: I think we need to be date-driven at this point.
Ian, did the http://www.w3.org/2001/tag/webarch/uri-res-rep.png rep'n diagram have text in the "representation" box?
DC: I am not yet satisfied that the TAG ftf meeting is clear enough about which document we'll be discussing.
I think the diagram is misleading now.
W3C process calls for ftf agendas 2 weeks in advance. I expect documents to stabilize in at that time. I gather I'm not gonna get what I want this time.
Resolved: If IJ finishes draft by tomorrow, we will review that at the ftf meeting.
I can't seem to find my last end-to-end review... I'm pretty sure it was a bit before 1Aug.

1.3 TAG update at Nov 2003 AC meeting.

  1. Action CL 2003/10/27: incorporate input on AC slides and produce another draft. See (proposed slides from CL)

The TAG expects to review slides during its face-to-face meeting.

2. Technical (75min)

  1. XML Versioning

2.1 XML Versioning (XMLVersioning-41)


Current draft is 3 Oct 2003 finding

  1. Action IJ 2003/11/03: (Issue XMLVersioning-41) Review XML Versioning text, propose a shortened form to DO and NW for their consideration, including good practice notes. See proposal from Ian.


DO: IJ, NW, and I also talked about use of namespaces names on the thread.
IJ: See status section for my expectations regarding namespaces.
DanC, you wanted to note problems with "Only namespace owner can change namespace"
DC: Not all namespaces have owners. Delegated ownership is a special case. I'd prefer to generalize rather than limit scope. The general point is that the Web community agrees on what URIs mean.
IJ: I wanted to address issue of "changing namespaces" by saying "Document your change expectations"
TBL: I think we can include the specific case of http; you lose a lot of power in generalizing.
DO: What about URN?
TBL: What if they use a UUID? Depends on the URN scheme.
NW: The URI Scheme shouldn't have any bearing on this discussion.
TBL: HTTP allows you to own a URI, through DNS delegation, you have a right to declare what it means. In those circumstances, it makes sense to state your change expectations.
[TBL seems to support IJ's proposal to include a good practice note to document change policy]
DO: One of the problems I had with IJ's proposal is that it didn't include all of the good practice notes that were in our text. In particular, requiring a processing model for extensions.
[good practice notes are fine in specific cases of general principles; but if we can't say what the general principle is, we haven't done our job]
s/User agent/agent/

IJ: Yes, that's a bug.

is there some reason to rush this discussion?
I want some text in the 11 Nov webarch draft.
ah; I see, thx Norm.
DO: I think these strategies need to be called out even more.
PC: I have not yet read IJ's proposal since he sent Friday. Stability of namespaces should appear in finding. I would support more advice on namespace change policies. There seems to be a tremendous amount of content on single-namespace languages; less on multiple namespace strategies. Is the finding focused on a single namespace problem?
DO: That is one of the splits in the finding. The finding doesn't go into enough detail on pros and cons of extension strategies on the use of multiple namespaces.
PC: I was just pointing to IJ's point on stability. I think we have to seriously consider talking about mixed namespace docs since that's one of our issues.
TBL: namespace policy for W3C specs is linked from W3C Guide. The requirement is to indicate change policy; also when namespace becomes fixed (at CR).
It is policy.
PC: We could include W3C policy as an example in arch doc.
Norm, you wanted to note that Ian said "only make backwards compatible" but left that out of his proposed text
NW: Warning about putting namespace material in section on namespaces.
[IJ expects to include xrefs]
NW: For draft tomorrow, I'd like for us to err on the side of including more text rather than less. The one critical piece not in IJ's proposal is forwards/backwards, closed/open systems, development times.
TBray, you wanted to agree with Stuart's comment that the level of detail in webarch and the walsh/orchard draft is violently different
TBray: I don't think the community is close on semantics or even desirability of mixed namespace docs. I don't think we can go there yet. I have just read IJ's text. I agree with IJ's point that the level of detail of DO/NW text is greater than rest of arch doc. I would by and large be ok with IJ's text. I think IJ has come close to an 80/20 point. On for/back compatibility, I don't know that it is required to be included. I agree that the finding should have the details since these are complex issues. I am concerned that if you talk about f/b compatibility, you fall over the slippery slope that might require 8 pages of details. Perhaps mention f/b compatibility as an example of what's important, with a link to the finding.
DO: Do you think additional material is required to be sufficient?
TBray: IJ's draft is close to being sufficient. It's fine for the arch doc to point off to findings for more detail.
timbl, you wanted to note that the ownership and change issues with nmaepsaces are similar to te problems with document in general, and expectation shoudl be set. And to say yes there is something. and to say yes there is something. http://www.w3.org/1999/10/nsuri : Note that a condition of documents reaching CR status will be that the clauses 2 and 3 will no longer be usable, to give the specification the necessary stability.
TBray: I don't think IJ's draft is seriously lacking anything. Mention of f/b compatibility a good idea.
TBL: On the issue of mixed namespaces, it may be worth saying that if you are designing a mixed name doc in XML right now, no general solution. But that if you do so for RDF, there is a well-defined solution.
There is a well-defined solution for mixing of RDF ontologies.
RDF does not provide a solution for how to mix arbitrary XML namespaces for non-RDF applications.
DO: I propose to work with IJ to find a middle ground.
DC: It's ok for me if last call draft says nothing about versioning.
TBray: I"d be happier with IJ's most recent draft rather than nothing.
DC: The tactic of putting more text in and cutting back is not working for me.
NW: I would like the arch doc to include some text in the arch doc. I am happier with IJ's text than nothing; but I'd like to work with IJ to include a few more things in tomorrow's draft, and discuss at ftf meeting.
I would be OK with skipping versioning for the arch doc last call in the interests of expediancy of consesnsus of tag. Would be happier with ian's current text, if consesnus of tag.
NW: My slightly preferred solution is to add all of DO/NW good practice notes for discussion at ftf meeting.
PC: I have to go; I'm flexible on solution.
TBray: I am sympathetic for a subgroup to work on some text for inclusion in tomorrow's draft. I am not excited about adding a lot more stuff. Note that I'm a big fan of the finding. But I think we need to stick closer to IJ's level of detail and length.
DO: I would be disappointed if IJ's draft was the extent of material that was included in the arch doc.
I got lost somewhere; In Vancouver, we had a list of the issues that were critical path for last call for a "backward looking" last call. Now versioning seems to be in there. I guess I'll have to pay more attention.
DO: I believe more material needs to be in the arch doc (in particular good practice notes); the arch doc will go through Rec track. I think that things that don't go through the Rec track will not be taken as seriously, not get as much review, etc.
SW: If the TAG agrees that we consider versioning that important, we can put a separate doc through the Rec track.
DO: I think the middle ground for this text is closer to the middle.
For the record: IMHO Ian's text is better leaving this uncovered, but Ian is coming close to the 80/20 point and I don't want to see it get much longer than that
DC: So there's no principles in here about versioning.
TBL: Perhaps we need to get into sync on the timing of this.
I think procedurally the right thing to do is let Ian/Norm/Dave saw off what they can by tomorrow.
TBL: My assumption is that we will dot I's and cross T's if we are to be on last call track soon. We are going to find small things we want to clean up in the existing text.
is that a question from the chair? NO! we are *not* anywhere near "last call sign off". I think 2/3rds of the current draft isn't endorsed by various tag memebers.
TBL: The versioning text is interesting, but i need to look more closely at the text. In any case, we need a disclaimer that we are not done by virtue of going to last call. We will need a place to put ongoing ideas for the next draft.
As I said before, I will be sorely disappointed if we don't say something about this topic in V1.0 of the webarch document.
I hear you norm, but I'm not clear why.
timbl, you wanted to ask about timing
TBray: I hear some consensus to hand this off to DO/NW/IJ to come up with something short enough and includes enough material.
And I'll want to have an ad-hoc group on abstract component refs.

Although it was not recorded in the minutes, there was an action for DO/NW/IJ to work on text on extensibilitly, which indeed happened just after the meeting adjourned.

2.2 Review of Architecture Document writing assignments

The TAG did not cover the rest of the agenda.

Comments on 27 Oct 2003 Editor's Draft of the Arch Doc?

Editor's expectations: Review a todo list that will be incorporated into an Editor's Draft to be made available 12 November.

Recent action items:

  1. Action IJ 2003/10/08: Starting from DO's diagram, create a diagram where the relationships and terms are linked back to the context where defined. Ensure that the relationships are in fact used in the narrative; any gaps identified? With DO, work on term relationship diagram.
  1. Action CL 2003/07/21: Discuss and propose improved wording of language regarding SVG spec in bulleted list in 2.5.1.
  1. Action NW 2003/10/08: Revise QName finding. See draft finding from NW. We will also add those two good practice notes to section 2:
    1. If you use Qnames, provide a mapping to URIs.
    2. Don't define an attribute that can take either a URI or a Qname since they are not syntactically distinguishable."
  1. Action RF 2003/10/08: Explain "identifies" in RFC 2396.
  1. Action TBL 2003/07/14: Suggest changes to section about extensibility related to "when to tunnel".
  1. Action DC 2003/07/21: Propose language for section 2.8.5 showing examples of freenet and other systems. Progress; see URISchemes/freenet

2.3 Review of 3023-related actions

  1. Should we open an issue or reopen a TAG issue?
  2. Action CL 2003/10/27: Draft XML mime type thingy with Murata-san
  3. Action TBL/DC 2003/10/08: Talk to the Architecture Domain Lead.

2.5 Findings

See also TAG findings home page.

2.2.1 Expected new findings

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