W3C home > Mailing lists > Public > www-qa@w3.org > February 2005

[Hot Topic] Extension and Versioning

From: Karl Dubost <karl@w3.org>
Date: Wed, 16 Feb 2005 19:31:46 -0500
Message-Id: <7743d0104ec03b1ab2b18c2d72fc6c78@w3.org>
Cc: Tim Boland <frederick.boland@nist.gov>
To: W3C QA Interest Group <www-qa@w3.org>
The Technical Plenary 2005 will have a Panel on Extension and  
Versioning of W3C Technology. Tim Boland (NIST) will participate to the  
Panel with the QA WG hat.

The topic matches with different background materials already available  
at W3C.

* TAG addresses the topic in “Architecture of the World Wide Web”

4.2. Versioning and Extensibility

Extensibility and versioning are strategies to help manage the natural  
evolution of information on the Web and technologies used to represent  
that information.
]]] - http://www.w3.org/TR/webarch/#ext-version

And defines good practices for it.

* QA WG addresses the extensibility topic in “QA Specification  

To accommodate changes in technology and information on the Web, a  
specification can be designed for extensibility. A specification is  
extensible when it provides a mechanism to allow an external party to  
create extensions. Extensions incorporate additional features beyond  
what is defined in the specification. However, extensions can  
compromise interoperability if there are too many differences between  
implementations. The impact of extensions can be mitigated through  
features specifically designed to allow new functionality. These  
features provide a 'standard way to be non-standard' by including  
hooks, conformance rules, or other mechanisms by which new  
functionality may be added in a conforming way, designated as  
extensibility mechanism.
]]] - http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#extensions

QA WG and TAG have started coordination on both documents.

The current Hurricane

xml:id specification has been released recently as a CR document and  
some issue have been raised with regard to the nature of xml:id and  
interaction with previous specifications. A few thread have been  
started on www-tag Mailing List about it. One of them is near 100  
contributions. (I give here the starting URI of the thread)

Some questions asked in the thread:
* What is the real meaning of a namespace?
	- space of names
	- identification of names
* Can we add elements to a namespace from spec to spec
* How a namespace interact with versioning?
* How a namespace interact with extensibility?

Note-Reference: Another point which has not been raised and  
demonstrates one of the point of Björn about normative references  
implications. If a deeper analysis of interactions with XML-C14N had  
been made for xml:id (and before xml:base), it might have avoided the  
problems of incompatibilities raised now.

Note-Test-Suite: How far a test suite must be pushed to detect this  
kind of incompatibilities?

Note-CoP: What is the class of products of xml:id ? Only xml processors  
or also specifications? Does the class of products could have helped to  
identify the bad interaction between c14n and xml:id specifications?

A few elements to understand the thread

XML 1.0, 3rd Edition defines the following attributes
Though XML 1.0, 3rd Edition doesn't define the XML namespace and  
doesn't define the prefix xml:. (ditto XML 1.1)

XML namespaces provide a simple method for qualifying element and  
attribute names used in Extensible Markup Language documents by  
associating them with namespaces identified by URI references.
	[[[The prefix xml is by definition bound to the namespace name  
It's not part of XML but on top of XML. It somehow extend the nature of  

XML C14N describes a method for generating a physical representation,  
the canonical form, of an XML document that accounts for the  
permissible changes. Except for limitations regarding a few unusual  
cases, if two documents have the same canonical form, then the two  
documents are logically equivalent within the given application  
context. Note that two documents may have differing canonical forms yet  
still be equivalent in a given context based on application-specific  
equivalence rules for which no generalized XML specification could  

xml:base proposes a facility, similar to that of HTML BASE, for  
defining base URIs for parts of XML documents.
xml:id defines the meaning of the attribute xml:id as an ID attribute  
in XML documents and defines processing of this attribute to identify  
IDs in the absence of validation, without fetching external resources,  
and without relying on an internal subset.
	then extending the nature of XML.

Thread References

* Significant W3C Confusion over Namespace Meaning and Policy (very  
long thread)
John Boyer

* Request for new TAG issue: Adding terms to a namespace
Norman Walsh

* Trying to assess the depth of xml:id and c14n incompatibilities
Daniel Veillard

* [Adding terms to a namespace] XML Events
Björn Höhrmann

Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

Received on Thursday, 17 February 2005 00:31:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:36 UTC