27 February 2002
These are the minutes of the W3C Technical Plenary, held on 27 February 2002 at the Royal Hôtel Casino in Cannes Mandelieu, France. This public event consisted of five presentations by W3C participants, followed by an open "Town Hall" session. This was the second Technical Plenary; (the first took place in March 2001).
In addition to the one-day Technical Plenary event, over 20 W3C Working Groups and Interest Groups held face-to-face meetings over four days at the same location.
Stephen Watt (Math Working Group, University of Western Ontario): What is the current resources allocation, say for our Working Group?
Steve Bratt: Members are able to refer to the W3C Effort Table (Member only link).
Janet Daly: MathML is in "life after Recommendation." As such, the Math Working Group has the mandate to produce additional materials (schemas...), which may not require as much W3C Team resources as one needs before Recommendation. So, the amount of resources spent on a Working Group depends on their state. Other Working Groups require more Team resources. Math Working Group Team support is provided by Max Froumentin.
Paul Cotton (XML Query Working Group Chair, TAG, Microsoft): The amount of Team resources required by a Working Group until Recommendation varies. For the moment, we have a constant % in the week from the Team. When a document goes to Last Call, you need more Team resources. So I wonder how realistic are our charters. Any thoughts?
Steve Bratt: It is an area we can explore, particularly in evaluating future charters, and to provide better future planning.
Moderator: Paul Cotton (XML Query Working Group Chair, TAG, Microsoft). Panelists: Dan Connolly (Semantic Web Activity, TAG, W3C), Chris Lilley (Graphics Activity lead, TAG, W3C), David Orchard (XML Protocol Working Group, Web Services Architecture Working Group, BEA), Norm Walsh (XML Core Working Group, XSL Working Group, TAG, Sun), Stuart Williams (XML Protocol Working Group, TAG, Hewlett-Packard).
Michael Rys (XML Query Working Group, Microsoft): If a Working Group brings issues it is having trouble resolving to the TAG, won't the process grind to a halt? What is the expected impact of TAG work on your average Working Group?
Paul Cotton: In several cases so far, the TAG has not been the first locus of resolution for a problem, but another group within W3C has been more appropriate. I've redirected questions to more appropriate forums. My observation in the first weeks of the TAG is that groups had a number of dormant issues they were waiting to raise.
Note that the TAG charter does state that the TAG's mission includes resolving issues involving general Web architectural issues brought to before it. TAG resolutions will be binding (as are other architectural Recommendations such as the Internationalization Activity's Character Model in review), but after review (on the Recommendation track). For example: Register your MIME type before your format specification becomes a Recommendation. Dissemination of our findings is important; we are learning better how to do this with practice.
Roland Merrick (XForms Working Group, IBM): We want to reuse specifications, but this creates lots of interdependencies, and as you move up the stack using a modular approach, this drags a lot of weight with it. What does it mean to implement against modular specs? How do we organize modules? How do they work together?
David Orchard: This is a buy v. build question. Modularity is an important design principle, notably from a feedback perspective. So far in W3C, I don't think we've done as well as we'd like with respect to using modularity. Perhaps the TAG should look at different factorings of specifications. The TAG has looked at modularity of XML, but I don't think TAG will undertake this itself. The TAG doesn't have a process yet to determine what we think from a modularity perspective. I'd like more input. We don't want the TAG to be seen as a "higher power with dictatorial authority." Rather, we hope to persuade and build consensus.
Noah Mendelsohn (XML Protocol Working Group, XML Schema Working Group, IBM): It's important for the TAG in the early days to establish the right relationship with other groups. I would strongly urge the TAG to foster consensus rather than to provide answers in the form of "The TAG decided this or that." Help people find answers (e.g., by helping them understand costs and benefits and trade-offs in modular design). I also think that education is important (e.g., in the face of misunderstanding about URIs).
Paul Cotton: Like other W3C Working Groups, the TAG makes decisions, gets consensus, and is accountable for those decisions. The architecture Recommendations we will produce will follow the Recommendation track process. How do we lead by example? Partly by being up here (before you) today, but also by reporting and keeping people informed.
Noah Mendelsohn: In my mind, TAG would be more effective if it were not like every other Working Group; instead, consider everyone to be an extended participant in the group instead. Do whatever you can to let people know when they should be involved, and get them involved.
Rigo Wenning (Privacy Activity lead, W3C): Please add "Security" and "Privacy" to Dan Connolly's list of principles.
Chris Lilley: That list is not exhaustive.
Dan Connolly: I note that other groups are producing architectural Recommendations (e.g., Internationalization, Web Accessibility Initiative guidelines).
David Orchard: Documenting trade-offs is important.
David Orchard: I'm wary to take on security issues in the TAG since we don't have the expertise. When issues arise, we will turn to the most appropriate group for help in dealing with the issue.
Jim Larson (Voice Browser Working Group Chair, Intel): So far, the TAG seems mostly reactive - people bring problems to TAG. What about proactive work? Will the TAG work on predicting upcoming problems?
Dan Connolly: Collecting pieces will help us spot future problems. I hope that shared understanding will, in general, help alleviate problems.
Jim Larson: I didn't mean spotting problems as much as providing guidance towards future technologies, etc.
Dan Connolly: There have been comments that we aren't doing enough top-down work.
Chris Lilley: Our charter says:
"The TAG will not just document what is widely accepted; it will also anticipate growth and fundamental interoperability problems. Elaborating the intended direction of the Web architecture will help resolve issues when setting future directions, help establish criteria for starting new work at W3C, and help W3C coordinate its work with that of other organizations."
Paul Cotton: Yes, our charter includes requirements to write. But I think that it will take the TAG a while to get to where you'd like us to be.
Jeremy Carroll (Hewlett-Packard): Are there plans to take the TAG's architectural Recommendations to Candidate Recommendation? What would that mean?
Paul Cotton: That's a good question for us to take back and think about.
Stuart Williams: How about: we need to find at least two people who find our output useful? The output has to meet a need, solve problems, be useful.
Dave Hollander (XML Schema/XML Coordination Group co-Chair, Contivo): I heard outpour for modularity. One unintended consequence of modularity is a loss of interoperability. Please consider that in your discussions.
T. V. Raman (Voice Browser and Multimodal Working Groups, IBM): The Web took off because authors could publish without worrying about which browsers people would be using. That principle seems to have been lost. I'd like to ensure that we are building a Web where you don't have to ask the user what browser he or she is using.
(There was general support and applause for T. V.'s comments.)
Dan Connolly: Hear! Hear! I'd like an hour to talk about this! The Web is breaking because people assume everyone has only one piece of software.
Tantek Çelik (CSS Working Group, Microsoft): On Dan Connolly's list of principles, where is "design for ease of authoring"?
Dan Connolly: This is related to the principle of least power.
Tantek Çelik: It's not clear to me that cleanest architecture gives you the easiest authoring environment. The Web grew since it was easy to author a document for the Web.
Paul Biron (XML Schema Working Group, Health Level Seven/Kaiser Permanente): I suggest that one way the TAG can be more proactive and improve dissemination of ideas is to bring Chairs together to work more frequently. Have the TAG do new Chair orientation.
(There was general support for the TAG sending representatives to Working Groups for education and outreach.)
Janet Daly noted Team resources (Ian Jacobs) have been allocated to the TAG to promote education and outreach.
Daniel Veillard (XML Core Working Group invited expert): I would like the TAG to clearly document mistaken choices so that we can learn from them, too. The TAG represents technical expertise. W3C is mature enough to know what works and what doesn't work. There may be a number of reasons why an effort does not succeed: Lack of Member interest, doesn't quite fit in the Web architecture, didn't appear at the right time....
David Orchard: Taking the XML Fragment example - this might be a case of a technology being too early. E.g., the problem we were trying to solve may not have been common at the time. I'm not sure how we could have prevented that particular problem from occurring.
Resources:
Moderator: Eric Miller (Semantic Web Activity lead, W3C). Panelists: Brian McBride (RDF Core Working Group co-Chair, HP Labs), Dan Connolly (Web Ontology Working Group Team contact, W3C), Ralph Swick (Semantic Web Advanced Development Initiative, W3C)
Martin Dürst (Internationalization Activity lead, W3C): As a Working Group, we invest a lot of time in tracking Last Call comments. ... Are there any tools for this?
Dan Connolly: Ian, Tim and I are trying to automate this in one group.... State of the art is: no tools right now.
Martin Dürst: I would like to help.
Brian McBride: RDF Core is coming to Last Call soon, and if I can find time I'll work on it also.
Andrew Hunt (SpeechWorks): Have you looked at commercial or publicly available products for issues tracking? Such as Bugzilla? ... Suggestion: use CVS repository for shared specifications. ... Jigedit doesn't help as much as I want.
Ted Guild (W3C): Bugzilla is not specific enough for W3C.... We started with the TAG Working Group to look at it.... but would like input from Working Groups.
Dan Connolly: Jigedit uses CVS underneath and uses people resources to maintain Jigedit accounts.... but it is available.... There is more info in the Guide (Member only link) about using it.
Steven Pemberton (W3C/CWI): How do you decide which tools to use?
Dan Connolly: Decided mostly in Chairs meetings. No formal process. How many of you have your own home-grown issues tracking system?
(Many attendees indicate that they use their own issue tracking system.)
Steven Pemberton: I suggest that W3C address issues tracking tool need.
Eric Miller: I suggest a birds-of-a-feather (BOF) table on this at lunch. CSS spec and Bugzilla creating an annotated version of the spec with direct links to bugs.
Janet Daly: But remember: the Semantic Web group is not SysTeam II.
Ian Jacobs (W3C): I want to use Jena tomorrow. How can I use it?
Brian McBride: Jena is not really born yet.... I have to recompile each time to use it! ... If there is demand, we will try to make it available.
(Several hands are raised indicating interest.)
T. V. Raman: Archived mailing lists are extremely valuable.... but it's painful to screen-scrape it out of HTML.... Can it be available in other ways? ... More specifically, can we have IMAP access to the archive?
Gerald Oskoboiny (W3C): We discussed it before. Decided to make monthly mailboxes available i.e., permanent URLs for each list.
Colas Nahaboo (ILOG): Suggestion: Use TWiki.
(Session adjourned for lunch.)
Moderator: David Fallside (XML Protocol Working Group Chair, Web Services Coordination Group Chair, IBM). Panelists: Jonathan Marsh (Web Services Description Working Group Chair, Microsoft), Jeff Mischkinsky (Web Services Architecture Working Group participant, Oracle), Philippe Le Hégaret (Web Services Description Working Group Team contact, W3C)
Henrik Frystyk Nielsen (XML Protocol Working Group, Microsoft): I have a problem with the definition of a Web service.... It sounds like any other machine communication definition.... How can we make sure the groups stay in sync? ... The definition of a Web service seems at odds with SOAP 1.2.
Jonathan Marsh: We have a Web Services Coordination Group also. We hope that will resolve that.
Jeff Mischkinsky: I think you might be reading too much into "request/response".... I think it is meant more as a generic "You send an XML doc, and it's processed" ... there are several scenarios.... People seem to consider most to be Web services.
Henrik Frystyk Nielsen: Would an event notification scenario be a Web service? ... e.g., "Your boat is on fire."
Jeff Mischkinsky: I think it fits the definition of a Web service.
Leigh Klotz (XForms Working Group, Xerox) on IRC: What about WS-I? What is its relation to the W3C Web Services Activity?
Philippe Le Hégaret: From their Web site, the stated goals are to build test suites and profiles, not specifications. We have sent questions on behalf of W3C; as they are just getting started, we expect they will come back to us with answers. At this point, we hope they will do systems integration and define test suites for interoperability.
David Fallside: One of the Coordination Group's roles is to figure out liaisons. ... WS-I is at early stages. This will evolve. Both sides are aware of it and want the right things to happen.
David Orchard (BEA): Interesting that the 3 groups listed have requirements and use cases ... and there's discussion of rechartering, etc. ... Is there the notion of reusing these things? Usage scenarios, etc.
David Fallside: Excellent suggestion.
Jeff Mischkinsky: I agree. No reason to reinvent the wheel.
Jonathan Marsh: I agree. Perhaps the architecture group could own master list.
Jacek Kopecky (XML Protocol and Web Services Description Working Groups, Systinet): ... There is an ongoing debate about intermediaries in XML Protocol..... WSDL doesn't stand intermediaries.... How much are the other Web services Working Groups aware of this issue?
Jonathan Marsh: We're too new as a Working Group to know. Haven't discussed it yet. But since you're on the Working Group, I'm sure we'll hear it!
Jeff Mischkinsky: We have started an issues list. Already have one from another Working Group.
Henrik Frystyk Nielsen: How can the Web Services Description Working Group deal with the type of extension you see in SOAP? ... There's no reason why extensibility could not handle this.
Jean-Jacques Moreau (participant in both Working Groups, Canon): ... I forwarded requirements and usage scenarios from the XML Protocol Working Group.... One, e.g., talks about intermediaries.
Paul Cotton (participant in XML Protocol Working Group): Possible strawman answer: Don't recharter XML Protocol, but give an extension. Pass the question about attachments to the architecture Working Group to make a recommendation to the Membership.
Janet Daly: Sounds great until it's time to draw a charter with different deliverables. The Membership still needs an opportunity to review that.
Paul Cotton: I was suggesting that the XML Protocol Working Group charter be extended with its existing deliverables.
Noah Mendelsohn: The Web Services Architecture Working Group should be involved in making decisions about attachments.... Another idea: Maybe W3C will eventually bless some kind of attachment architecture.... Maybe we need an enabling hook in SOAP.
David Fallside: I don't think putting in such a hook requires a new charter.... Typically you can do a "pro forma" recharter to buy more time without changing the charter.... But to change charter requires Membership consent.
Noah Mendelsohn: My recollection is that the Working Group was forbidden to work on attachments, but I may be wrong.
David Fallside: Someone noted that the definition of "Web service" did not include the word "XML"!
John Ibbotson (IBM): For SOAP in Web services, there will be additional headers... e.g., message description header, ... routing proposals, reliable delivery.... Does the Web Services Architecture Working Group intend to identify such things and define them?
Jeff Mischkinsky: That would be something to put to the architecture group. ... I could see other info also. ... It would be useful to have a registry of these [scribe lost comment]. ... for important ones we need a methodology for them.
David Orchard: Prioritization issue: For Web Services Architecture Working Group, time to market should be explicitly written as a goal. ... Does the Coordination Group have responsibility for scope? ... How do the 3 groups deal with scoping of new/recharter groups? ... Use case: Web Services Architecture group says a reliability header is needed. What happens?
David Fallside: The Coordination Group charter includes responsibility to ID new groups. ... Coordination Group also has responsibility to bump things up to the Advisory Committee and Team.
Jeff Mischkinsky: Part of the reason these groups were chartered was to address these questions. ... We'll need to address them using consensus, and have them considered in the larger scope of the organization.
Moderator: Daniel Dardailler (W3C Deputy Director for Europe, QA Activity lead, WAI Technical Activity lead). Panelists: Lofton Henderson (QA Working Group co-Chair, CGMO/OASIS), Steven Pemberton (Chair HTML and XForms Working Groups, W3C/CWI), Ian Jacobs (User Agent Guidelines Working Group Team contact; Process, AB, and TAG editor; W3C), Paul Grosso (XML Core Working Group co-Chair, Arbortext)
Misha Wolf (Internationalization Working Group Chair, Reuters): I'm happy with the XML Core Working Group errata system, but what happens with Working Group approval of errata? We should avoid ambiguity in specs and corrections, so I want clear and rapid process for errata. The problem is approval of Advisory Committee representatives. I propose that AC reps register for each spec errata they want to monitor; then they will receive email about concerned errata and then there will be a voting period. This would ensure a minimal period of vagueness.
Jeremy Carroll: Consider the cost of test cases: my experience is that they have actually reduced costs. In RDF core, we had a simple yes/no system that has reduced discussion.
Lofton Henderson: We had the same experience in the SVG Working Group.
Dan Connolly: I'm concerned about the meaning of Last Call. It was said "double check 2 weeks before you request Last Call." But that is Last Call. Last Call is in effect First call, as people will review the spec for the first time then. The review must start before Last Call.
Steven Pemberton: I don't see how this could happen. Most people wait for Last Call anyway.
Henry Thompson (wearing XML schema editor hat): I strongly agree with Paul Grosso about separating issues and errata management. Issues should be linked from the Working Group page, not in the document. I would like clarification on who's the gatekeeper of 2nd editions of specs.
Responding to Misha: I'm not aware of a single controversial errata. Working Groups are in control of their errata and have been responsible for not publishing harmful corrections. The current process is OK and does not need to change. The Working Group makes the errata normative and that's all the process we need.
Paul Grosso: Within the Working Group we can announce the errata to the Chairs mailing list and set a countdown period after which it becomes normative.
Paul Biron: I suggest to the owner of W3C's publication rules to make errata more visible by having pointers to them from various places.
Janet Daly: Acknowledged.
Arnaud Le Hors (XML Core Working Group co-Chair, Patent Policy Working Group, IBM): There are legal implications about requirements documents. And so they should be part of the process.
Ian Jacobs: The Advisory Board (AB) discussed it. Requirements documents sometimes set wrong expectations. The AB decided that it shouldn't be a requirement to have requirements documents. Danny Weitzner will take that issue to the Patent Policy Working Group.
Daniel Veillard: 1. Test suites are extremely valuable. 2. What is the limit of a test suite, i.e., where is the point after which a test suite becomes normative? 3. What is the "officialness" of a test suite?
Daniel Dardailler: Our goal is to bring closer test developers and Working Groups. This does not mean that test development has to happen in the Working Group.
Daniel Veillard: But if the Working Group writes the test suite, it can be fixed faster.
Masayasu Ishikawa (HTML Activity lead, W3C): There is no process about editorial revisions of specs (2nd editions and such). For XHTML 1.1 2nd edition, the Working Group was asked to follow XML 1.0 2nd edition, but the process was not written down. I would also propose to get public review before all publications of Recommendation revisions. Second, what should be the best practice to manage errors in DTDs and schemas? How do you fix an error in a DTD in the text of a spec?
Ian Jacobs: Would the proposed errata process meet your needs?
Masayasu Ishikawa: No.
Daniel Dardailler: That's something we'll discuss off-line.
Karl Dubost (W3C Conformance Manager, QA Working Group co-Chair): Allocating resources for QA in Working Groups is not a problem if it is decided at the beginning of a Working Group's life.
Moderator: Steve Bratt. Panelists: David Orchard, Eric Miller, Janet Daly, David Fallside, Daniel Dardailler
Steve Bratt: Any general comments?
Daniel Veillard: Curves were interesting - number of specs - also interesting how much time each spec took.
Steve Bratt: Planning to do that.
Tantek Çelik: Data on document was interesting - wondering how chart would look with number of test suites imposed.
Daniel Dardailler: See the Matrix - how many endorsed test suites there are.
Karl Dubost: There is now a W3C icon on W3C recognized test suites.
Dave Hollander: Will trajectory flatten off? Will we do more specs in a year? ...
David Fallside: Even with count being flat, number of interactions between specs goes up at a huge rate. This has been a concern of mine. A major inhibitor of progress. We should be tracking number of interactions from resource point of view.
David Orchard: I see specs like software. We should do feature count, lines count - fallacy in terms of code metrics apply in terms of spec metrics. I am not sure that this gets to the core. Data will stay flat, since Membership stays flat
Janet Daly: We may have flat membership, but Working Groups often contain more people than the whole W3C Team.
Steven Pemberton: This is only the second tech plenary. Has it been a success? What went wrong? ... Should discuss. I missed worked up discussions of issues in plenary, e.g., the role of namespace as profile identifier. Presentation and question sessions were not open enough.
(Show of hands suggests more technical presentations.)
T.V. Raman: Should get topics from Chairs mailing list.
Janet Daly: We did solicit them.
David Fallside: In the Web services session, there were meaty technical issues. It was our intent when planning this plenary to have a 50/50 mix of technical and process. Maybe today was too much process. We tried to seed discussion on technical stuff, but that didn't happen.
Steve Bratt: Who wants more technical presentations? (80% raise hands.) Who thinks we can find more four topics ...
Dave Hollander: I heard only organizational presentations today. Didn't learn anything about the Semantic Web.
Janet Daly: Do you want to hear Working Group presentations?
Henry Thompson: We did do that for XML Schema, and it was a good thing.
Jim Larson: I liked slides that showed what we accomplished. Also interested in what went wrong (how many specs did not go to Last Call etc.), and the reasons for that. Help stop mistakes in the future.
Graham Klyne (MIMEsweeper Group): Intermixing/plenary effect is stronger in the IETF. This meeting is too big for meaty technical issues. Maybe could start with plenary, then break out into smaller groups.
Dan Connolly: Some people don't like to talk to large crowds and come to the mike. BOF tables were interesting. Real work happens in hallway meetings.
Unidentified speaker: Too big a meeting for technical discussions. Wanted to get background on topics that I don't follow but am stuck in Working Group meetings. Parallel tracks today would have been good.
Daniel Dardallier: Should TAG be setting up the agenda of this meeting? They should know "hot topics." Too early for this time, but maybe next time.
David Orchard: Let's take namespace name. We had a TAG face to face meeting and spent 3/4 hours on that. Need context to get through. I don't think much active debate is possible in this forum.
David Fallside: I like the idea of parallel sessions. Long running BOFs or associated with special Working Groups? How would that work?
Daniel Veillard: Missing XML plenary - smaller than this forum, addressing technical issues. Fruitful to have two Working Groups share a meeting. Something which takes 3 months by mail gets resolved in 30 minutes.
Graham Klyne: The IETF model is to have Working Group sessions of 1-2 hours, then break, and only a few plenary sessions.
Paul Biron: Health Level Seven is a standards body. Our meetings are typically a week long. Chairs need 9 days. I liked the W3C way - 1 or 2 day meetings.... Multiple tracks, tutorials sound like a good idea. Joint meetings are very good, but hard to coordinate.
Wendy Chisholm (W3C): A comment on TAG organizing this day: We have tech reviews in the W3C Team to discuss technical discussions, and also workshops. The TAG could become a body where Working Groups come together and propose a technical review. Then the TAG selects three or four for the plenary.
David Booth (W3C): It would be difficult to discuss detailed technical issues in this forum. I like the idea of technical presentations, but should be applicable to everybody, or in multiple sessions.
Paul Cotton: I like the idea of TAG organizing this meeting. Want to talk about QA. Have test suites ready at beginning of CR. RDF core experiences with test cases. Candidate Recommendation is not mandatory. Measure to enforce interoperability. Having test cases before optional step is wrong. Need use cases and test cases much earlier. That encourages people to look at the spec early. Encourages early implementations. We have 12 implementations of XML Query because we used that strategy. It allows you to catch errata before you publish. Encourage the W3C in helping Working Groups how they should develop test cases as early as possible. Would like to get to the point where we don't need Candidate Recommendation because we already have implementations. Specs fail because they haven't built up a community.
Janet Daly: Requirements for Candidate Recommendation are mandatory....
Jonathan Robie (Software AG): I support Paul's statement. Use cases and requirements documents are an important part to help outsiders understand work of a Working Group. All of our work needs to work together.
Eric Miller: I agree with Paul. A side-effect of RDF core is that examples are an educational experience....
Daniel Dardailler: QA is planning another column in the Matrix.... Some Working Groups have inherited test suites from another organization.... Should show where there is need for test development.
Arnaud Le Hors, comment to Paul: Resources in companies are stressed, it is hard to encourage implementors to change things over and over because of changes in the spec. There is a high cost involved. Query case cannot be generalized.
Daniel Veillard: What was the conclusion of the namespace discussion in the TAG?
David Orchard: Namespace names getting widely deployed. A namespace name may be dereferencable; you can't count on it for building anything. Some put an XML schema document there, others put an HTML document, others put RDDL, or RDF schema. Could leave as is, could say that something should go there. But what? ... Trying to figure out use cases and requirements. Who will use this: human or machine - I believe we should have an HTML document. Web Services won't use a namespace name to validate. We don't have consensus in the TAG.
Paul Cotton: A minority of the TAG agrees that there should be human readable material at the end of a namespace. You don't have to do that ... something like RDDL. Other TAG members disagree. Dave and I don't think it should be XML schemas. Was intrigued by the number of people that were interested in what TAG was doing. The charter says that we have to report to the Advisory Committee. The TAG should consider how we report to the Technical Plenary community.... We may have given TAG too much on the Advisory Committee level, and not enough on the technical level.... Will try to report more to tech plenary community.
Larry Masinter (Adobe): Why namespace name issue is hard: Most W3C languages talk about language syntax and semantics, but this is about operational practice, recommendation to Webmasters.... The words "should" and "must" don't really apply.
David Orchard: "Best practices" came up during a lunch discussion.... Could be TAG output.
Judy Brewer (W3C): The Web Accessibility Initiative (WAI) Education and Outreach group will talk about "best practices" on Thursday.... Want to extend and co-promote other areas of W3C ... There is a huge potential for mutual advantages.... Could cover Device Independence, Privacy, best use of metadata.
Graham Klyne: I don't think that best practices should have normative force - but others don't agree.
David Orchard: Do we do conformance testing against namespace rules - open issue. Would worry about trend if specs avoid making decisions and put it into best practices instead. There are process issues around this.
Graham Klyne: A Recommendation that may not be interoperable without best practice would be problem with the Recommendation.
Daniel Burnett (Nuance): Comment on QA. In the Voice Browser Working Group, we have dozens of implementations - applications running millions of phone calls. Huge call from industry. Helps in narrowing down the spec. Great that we had all the feedback from industry. Hope we can go to Last Call and Recommendation as quickly as possible.
T. V. Raman: The distinction between "Recommendation" and "Best Practices" is not clear on a language level.
Steven Pemberton: Public complaining about verbosity of required headers in HTML - XHTML 2.0 will be even bigger - can we do something about that?
Ray Whitmer (Netscape/AOL): Comment on patent policy. The TAG should maybe oversee patent policy. Work on definition of "essential" - in DOM, most of the things are optional, so patent policy does not seem to apply....
Janet Daly: Can comment on new patent policy Working Draft that came out yesterday. The Patent Policy Working Group does not live in isolation from the rest of W3C work.
Ray Whitmer: thought I had already brought up that comment, but have the impression that the Patent Policy Working Group does not make connection to technical work.
Arnaud Le Hors: I am a technical guy on the Patent Policy Working Group - we are aware of the issue.
Michael Rys: Essential patents are patents essential for features, not for essential features.
Ray Whitmer: I have not seen this definition - only mention of "essential for implementation."
Rigo Wenning: "Essential" can be defined by us, or by the courts, we cannot define this here.
Steve Bratt thanked the organizers. Adjourned at 17:30.