W3C | TAG | Previous: 18 Aug teleconf | Next: 15 Sep 2003 teleconf

Minutes of 8 September 2003 TAG teleconference

Nearby: IRC log | Teleconference details · issues list (handling new issueswww-tag archive

1. Administrative (15min)

  1. Roll call: TB, PC, SW (Chair), DO, NW (Scribe), CL. Regrets: RF, DC, IJ, TBL
  2. Accepted the minutes of the 18 Aug teleconf
  3. Accepted this agenda
  4. Next meeting 15 Sep teleconf. Regrets: CL

1.1 Scheduling

Completed action SW 2003/08/18: Review work plan from Vancouver F2F to help with schedule (done)

See below for information about Arch Doc scheduling.

[Norm]
SW: Hope for TR page publication of WebArch before Oct f2f Prospect for interrum editors draft on 17 Sep per Ian
PC: Looking at .../0037.html, thought we would swap 8 Sep and 22 Sep. So use 22 Sep for editor's draft review?
SW: Yes
PC: So I need to have NSDocument8 done by next Monday (15 Sep) Suggest extensibility today, NS for 15 Sep, editors draft review on 22 Sep
TBray: Commits to 15 Sep
SW: Sounds good to me
PC: Extensibility may pop up again
SW: Review comments by email before 22 Sep if IJ gets draft out in a timely fashion. I don't want to start at the beginning of the document Want commitment from TAG to submit comments in advance of the meeting
Accepted
SW: On 29 Sep, we'll catch up on findings
TAG congratulates Roy on his recent nuptuals
SW: No idea how we're going to generate text for interaction section
RF: No comments at this time.

1.2 charmodReview-17

[Norm]

SW: What should we do about I18N. They haven't told us anything officially.
TBray: They accepted many of our comments, but rejected our big one to split document.
PC: Why did they reject it?
TBray: They thought it would take too much time. But perhaps they put more thought into it than the record would suggest
SW: I could enter the dialog or leave it in DC's hands
PC: I'd prefer that SW enter the dialog. Them saying no doesn't help us understand why.
TBray: I agree, and I would add that we could note that the extreme delay in getting around to something as simple as addressing the commentary illustrates the problem
PC: +1 References were on tag-only, not publicly. We should say "the TAG has noted that..." and that will open the discussion
SW: I'm inclined to keep it within the thread that started it
Action SW: Follow up on the status of our CharMod comments
[TBray]
I'd like the record to reflect that the TAG still feels that the Web community is in urgent need of the results of their excellent work
[Norm]
TAG agreement

1.2 Bristol meeting planning (6 - 8 Oct)

See meeting page for information about suggested hotels.

Completed action SW 2003/08/18: Suggest hotel (done)

[Norm]
SW: I hope folks feel they have what they need. The purpose and motivation of the meeting is to do another cycle on the WebArch to get to LC. I assume that's what folks still want us to do
TBray: Agreed
SW: What about a hired car from LHR?: NW, PC, TBray, DO are interested
NW: Why doesn't everyone post arrival times and we'll work it out in email
SW: Julie will collate and contact the car company
PC: What about returns
SW: IJ wants to leave midday on Wednesday.: It is possible to get flights back late afternoon, if they wanted to

2. Technical (75min)

2.1 namespaceDocument-8

Status of work on namespaceDocument-8.

[Norm]
TBray: you've had the bad news
SW: How much of this work affects the WebArch doc?
PC: Don't know, but will try to include that in the finding
TBray: Volume of material in the WebArch document is modest
PC: Yes, but it would still be useful to provide the WebArch changes
Action PC: Provide finding and proposed WebArch text

2.2 Versioning and extensibility

[Norm]

SW: Thanks for working on it.
PC: I've read most of it
DO: Should we provide an overview
NW: I'm scribing, DO, please lead
DO: The purpose is to try to provide some firm guidance to specification writers on what kinds of things they should do (or the options and tradeoffs). In two areas: schemas and software. Finding tries to provide a methodology to design specifications and software such that backwards and forwards comaptible changes can be made to the specification. So that we can have newer versions of specifications rolled out in a well-defined manner. Obviously the topic of versioning is difficult, but there are a number of things that can be done wrt schemas and wildcards that can enable it. Document tries to explain why you want to do this, what can you do, what problems arise, and then we dive into what we suggest for W3C XML Schemas in particular. In particular we discuss some of the problems that arise as a result of determinisim in W3C XML Schema. Introduce notion about how you should design a schema, why its done that way, the notion of extension in the same and different namespaces. Talks about kinds of languages: extensions, containers, etc. Discusses rules for design in some of these language cases. Guidelines: you must specify a processing model, describes what some options are. And then a lengthy discussion of some alternative techniques. In works that this was somewhat derived from, there was a lengthier discussion of the schema issues and what schema could have done to make this a little easier, but that language has been toned down considerably
TBray: 1. It's a stupendous piece of work. Everything in here will find a use. No matter how many times I read it, I think the defs. of backwards and forwards compatibility are backwards. Did you have any angst about that?
NW/DO: Yes. Lots.
DO: Tries to explain.
NW: There's some angst. Maybe more explanation is needed.
TBray: I think just a concrete example like the one you just gave will help
DO: This comes right from FOLDOC
TBray: Let's lift a concrete example, it would help a lot. The most valuable lession I learned in years of pub. systems, is the extreme lack of consensus in the mental model of versioning. Your model is probably violently incompatible with the model of the guy sitting next to you. Words of caution is all I'm suggesting. I think that the thing would partition cleanly into a extensibility forwards/backwards compatibility policy note and a technical note about XmL Schema. One of the reasons we embedded it is because XML Schema is the basis of most of the W3C work. What I was worried about was that if we did it very generally and left the schema stuff somewhere else, the developer would see abstract stuff when what they really want is the technical stuff. Lots of folks aren't using W3C XML Schema. For example, the RSS folks would benefit from the policy note and don't care about the schema stuff
DO: Feedback understood. Let's think about that a little bit.
PC: You aren't telling us what material you want to change in the WebArch document. There's a section on extensibility, does it remain the same?
DO: We're not sure yet how much could be inserted into the architecture document. I'd like to see an encapsulation in the WebArch document. We thought it was important to find out if the TAG agrees first.
PC: The theme appears to be largely focussed around distributed applications and web services. I was hoping you'd talk a lot more about extensibility for the existing we developer today. Maybe that's the point that the TBray was making. For example, some folks don't know when to change a namespace URI. I would have thought that something along those lines was what we wanted in the first architectecture document. At the very end of Section 7, there's a paragraph that says "As you can see..." That's the heart of the matter.
DO: So you'd like to see some more emphasis on that rule about reusing namespaces in a more general kind of manner
PC: The places we can't get agreement today are things like when do you change the namespace when you're working on a spec? At every draft? Does it stop changing at Last Call? I think we need to say something "simpler" or "more grounded in existing practice" in V1 of the WebArch document. I wonder if Dan was saying the same thing in his initial response.
DO: I've read through most of them quite throughly.
PC: I guess my emphasis is that I would tend to agree with TBray. For example, how should I manage versioning of the namespace for the F&O document in XQuery. It's just a namespace with a bunch of function names. The general principles up front might apply, but you haven't really helped me. I don't think you have enough to say on that and way to much on Schema. Splitting it into two parts and making sure the first part emphasises stuff more related to current practices would allow us to generate material for V1 of the arch. document
SW: I share some of the concerns of PC and TBray. Possibily a need to distinguish between vocabulary and language. There are words that appear here that might have archtectural import.
DO: That's why I wanted to have those words defined in the WebArch document
TBray: I notice for example that the Namespaces Rec introduces the notion of vocabulary without defining it
PC: F&O vocabulary is actually a list of functions
SW: Vocabulary is a list of terms and language draws on that vocabulary. One thing that jumped out as a principle: 5.2: The collorary that permision is required for extension in the same namespace...". That kind of statement felt like it was something of architectural merit. Most of the rest seemed like it was good practice (particularly in a schema context). What weight is intended for the rules? Are they, for example, bound for a Recommendation. Editorial obs. Section 4 reads like an introduction.
NW: Yes, it could have been cleaned up. But I insisted on publishing. DO wanted to polish
TBray: I'm on your side norm
SW: What about making it public
DO: How about we take another wack at it (organizationally) and then make that public
PC: What about the alternatives at the end
PC: Are you saying that none of the other alternatives in Section 10 fit the bill?
DO: Yes. You can't use type derivation or subst. groups in a bw/fw compatible manner with zero changes at the other side
PC: That's a pretty bold statement, you know.
DO: But it's true. If you've got an older version of the software, the only way it can know it's a backwards compatible version is to look at th enew type. That means the older software has the newer type.
PC: That's all about whether you live in an open or closed world. That's one of the four remaining issues that Query is battling with. In an open world, you can treat subtypes as a recognizable supertype. That's going to leave you open to some really strong criticism. In particular, you haven't subjectively described why your solution is better than the others. You've just pointed out why some of the others don't work.
TBray: One hole: it is popular in designing languages to have a version attribute on the root element. We're having a big fight about that in son-of-RSS land. This is related to what you can put in version= on the XML Declaration. I tend to be in favor of a version element on the root of most vocabularies unless there's a good reason not to. I think we'd have to cover that.
NW: There's a section in there about how using a version attribute lets you down
PC: No where in this document do you talk about negotiating the vocabulary between the sender and receiver. Isn't that a pretty common arch. design?
NW: Version numbers is the last five paras of section 3
TBray: I'll have to respond to that in detail
DO: It's good to know there's going to be pushback
PC: You thought this met an 80/20 cut. Version numbers often meet a 90/10 cut. So do namespaces. Where in the flavors discussion do you put changing the namespace for each working draft
NW: We need to describe the general cases in more detail
PC: That would motivate the the rest of the discussion, perhaps
[Stuart]
Did you guy's review this message (and surrounding thread) http://lists.w3.org/Archives/Public/www-tag/2002Sep/0092.html
[Norm]
PC: If you step forward from the simple problem, you'll get to what this document proposes
DO: We internalized a fair amount of the motivation, and settled on a particular case.
NW: Point taken.
[TBray]
NW: Nobody is suggesting that the document is wrong in what it says. Strong suggestion that it could be cleanly separated into general policy as distinct from special techniqieus for XML Schema. Plus insufficient motivation for versioning policies in distributed systems: and on vocabs that are just names like XQuery F and OOPlus distinction between dev time and deployment time, e.g. successive WDs change namespaces, but stop at some point in the process
SW: Which version do we take public?
NW: I'm OK with this one.
PC: if you split it, part 1 won't be controversial, part 2 will
PC: SQL does subtyping by extension, big-bang approach, it seems to work
[Norm]
SW: How about running it by HT?
DO: I have no objection, but I'd like to do a new version first. PC, I heard your point about motivation the first time
SW: Can you propose a date for rewrites
DO: 18 Sep.
NW: 18 Sep, ok.

Action NW and DO: Produce a new draft by 18 Sep

2.3 Status of overdue action items

Findings:

[Norm]

SW: I'd like to get some indication of when something would be ready
RF: So would I, but I can't give you one
SW: CL isn't here
SW: whenToUseGet-7 is close to finished, but waits action on DO
Action DO: Complete action by 12 Sep
NW: I am reminded everytime I scribe of how much effort IJ undertakes on a weekly basis and wish to publically thank hhim yet again

Below not discussed.

2.4 Architecture Document

Reference draft: 1 August 2003 Editor's Draft of the Arch Doc

What is TAG's expectation of editor at this point? For example:

  1. IJ closes loop on introduction with TB, RF (DC?). There was discussion at the 18 Aug teleconf about a rewrite of the abstract and introduction
  2. Editor's draft 17 Sep
  3. Reviewed at 22 Sep TAG teleconf
  4. IJ incorporates comments, gets review from two TAG participants, and requests 1 Oct TR publication
  5. New TR draft published 1 Oct
  6. TAG reviews 1 Oct draft for and at face-to-face meeting 6 Oct.

2.4.1 Review of actions related to Architecture Document

Open action items:

The following action items were follow-up from the 22 July face-to-face meeting in Vancouver:


2.5 Findings

See also TAG findings home page.

2.5.1 Draft findings nearing closure

2.5.2 Draft findings that require more discussion

2.5.3 Expected new findings

  1. Action IJ 2003/06/09: Turn TB apple story into a finding.
  2. Action PC: Finding on namespace documents, due 31 August 2003

2.6 Issues

The TAG does not expect to discuss these issues at this meeting.

2.3.1 Identifiers (URIEquivalence-15 , IRIEverywhere-27)

2.3.2 Qnames, fragments, and media types(rdfmsQnameUriMapping-6, fragmentInXML-28, abstractComponentRefs-37, putMediaType-38)

2.3.3 New and other Issues requested for discussion. (mixedUIXMLNamespace-33, RDFinXHTML-35, siteData-36 plus possible new issues)

Existing Issues:

2.3.5 Miscellaneous issues

3. Other actions


Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/09/11 13:31:55 $