W3C

XML-URI Activity Proposal

DRAFT ONLY, for discussion in xml-uri
possibly to proposed to the W3C Membership
by TimBL, Dan Connolly
$Revision: 1.2 $ of $Date: 2000/07/11 17:36:56 $ by $Author: connolly $
Note that public discussion of activity proposals is non-traditional, though not prohibited by W3C process. The traditional reason for keeping draft proposals confidential is that we want the membership to be free to give frank feedback on activity proposals, and prior public discussion of a proposal may result in suppression of dissenting views. However, this issue has already had sufficient public exposure that we estimate that public discussion of this proposal is not likely to burden the membership any further. With that said...

An activity is[@@may be] hereby proposed to produce a technical document providing answers to some essential underlying questions of the architecture of the Web, specifically the use of Universal Resource Identifiers in markup languages such as XML.

There has recently been a hiatus in the W3C process due to the uncovering of differences of assumption, between different parts of the web design community, about this issue. The discussion has focussed especially but not exclusively on their use (or not) in identifying XML namespaces

This proposal is for a public working group to debate this issue. That is: per section 3.1.1 How to Create an Activity and 3.2.3 charters of the W3C process, we propose an XML-URI Activity in the W3C Architecture Domain consisting of a XML-URI Working Group.

Context: History

Until now the W3C architecture has been basically been produced by the W3C staff, embodied either implicitly or explicitly in the charters of working groups in briefing packages, discussed in that context and generally in advisory committee meetings, and typically modified as a result of such discussions and also as a result of elaboration by working groups and the progressive development of the technology. These architectural assumptions formed the rather implicit framework which tied the W3C activities together, and would allow the technical products to function together as a greater whole.

One tension around this is that enumeration of underlying layers which in fact are assumed by everyone is time-consuming and unnecessary whereas omission when there are misunderstands leads to later disaster. Another is that while having the technical assumptions written (and ideally given a formal mandate) does make things clearer, as that set is in reality changing all the time there is the danger that it by becoming more concrete it becomes too inflexible and restraint to new ideas.

In the last couple of years, we went through a phase of awkwardness when a number of working drafts were developed which, in the eyes of some outside the working group, sometimes W3C staff members and the director, did not comply with the architecture as seen, and therefore threatened the integrity of the whole. This lead to a request, by working group chairs, for a rough but short list of some of the basic principals which were considered to be a part of the architectural framework. I responded by creating an Architecture from 50,000 ft document which tried to address this.

Most recently, the progression of the DOM specification[@@] toward Candidate Recommendation status highlighted a serious ambiguity (or inconsistency) in the XML-Namespaces specification. This led to a discussion, at first in the XML-plenary, and then in the specially created xml-uri mailing list

Scope

[@@assuming...] An interim step has been taken of deprecating the use of relative URI references in namespace declarations. However, while this removes the test cases which produced inconsistent behavior at this moment, it has left open discussion around a number of issues which I had imagined assumptions commonly agreed as underlying the core technology.

In scope:

Out of scope

Constraints

The discussion will not be [@@tim's draft is cut off here; I'm not sure what he meant to say.]

Recommended Reading

Process

The discussion will be available to the public, but the chair may take the step of limiting contributors if there is a problem with those which have not read the background material, or consistently work outside the scope of this or the manner of a W3C working group.

There will be a goal of a consensus document, but in the event of seriously different approaches, the group may forward proposals from subgroups. These may be proposed to the W3C Advisory Committee as alternative proposed Recommendations, or as a Proposed Recommendation with a minority opinion.

There may of course be a Candidate Recommendation period it is determined that practical application of the recommendations is necessary for their credibility.

Deliverables