- From: Richard Tobin <richard@cogsci.ed.ac.uk>
- Date: Thu, 28 Nov 2002 18:30:13 GMT
- To: w3c-html-wg@w3.org
- Cc: xml-names-editor@w3.org
This is a formal response from the XML Core WG to your comments on the Namespaces in XML 1.1 last call working draft. If we haven't heard from you by the end of Monday December 9th, we will assume for the purposes of our planned CR request that you have no objection to our resolution. Commenter email address: w3c-html-wg@w3.org > Subject: Last call comments for Namespaces in XML 1.1 >[...] > 1. This should not proceed to CR before exit criteria have been > agreed on, and those criteria should include conformance based on > a test suite. Summary: accepted We intend to produce a small test suite by the end of the CR period, and will require that two implementations pass it in full. > 2. It is difficult to see how you can *possibly* proceed to CR > until you include a definition of QNames as attribute > values. These are now widely being used, above all by XML Schema, > and not to define the meaning would be a major technical, > political and public-relations error. Summary: rejected We decided that such a substantial addition was not within the scope of this revision of the specification. > Now the textual comments. Summary: accepted in part Several parts of the spec have been re-written for the CR draft. In some cases your proposed changes have been accepted, in others the wording they refer to no longer exists. In some cases we just didn't agree that your wording was better. Some specific comments follow: > "[Definition: An XML namespace is a collection of names, identified by > an IRI reference, which are used in XML documents as element types and > attribute names. ]" > > This is a major source of confusion, because an XML namespace is *not* > "a collection of names" by any definition of "collection" that I > know. We have changed the wording, but decided not to incorporate a formal definition such as the one you propose. We have removed the non-normative appendix B with its description of namespace partitions. Instead we have incorporated the "expanded name" terminology of XPath (which is consistent with the Infoset and XML Schemas). > "Therefore, the namespace prefix serves as a proxy for an IRI reference. " > > This is an incorrect use of the word 'proxy'. A proxy is an active agent. > 'Alias' is the correct term here. This wording is no longer present, but we disagree that "alias" would be an appropriate term, since it suggests that the prefix and the IRI are interchangeable. You *must* use the prefix, not the IRI. > "For correct operation with such applications, namespace declarations must > be provided either directly or via default attributes declared in the > internal subset of the DTD." > > What does the 'must' refer to here? > 1) If you also want your documents to work with non-validating, you must > provide NS declarations > 2) You must always provide NS declarations (so that documents work in all > evironments). We have clarified this and issued a corresponding erratum to Namespaces 1.0. The intended reading is (1). > "Note that the prefix functions only as a placeholder for a namespace name. > Applications should use the namespace name, not the prefix, in constructing > names whose scope extends beyond the containing document." > > Now it has gone from being a proxy to a placeholder! Replace 'placeholder' > with 'alias'. > > But there is something terribly wrong with this paragraph: first it starts > with 'Note', which suggests it is non-normative, and then it uses the word > 'should', which I am pretty sure ought to be a 'must'. The use of "should" here matches the Infoset, and we decided even if it were desirable, such a change would be out-of-scope for this revision. > The correct namespace IRI for HTML is: > > <html:html xmlns:html='http://www.w3.org/1999/xhtml'> The HTML examples have been changed to use the XHTML namespace. The troublesome examples in appendix B have gone, along with the rest of that appendix. > "Note that default namespaces do not apply directly to attributes." > > This sentence causes more confusion and arguments than any other single > sentence in the spec (partly because of factors I have already mentioned). We now state that - the namespace name for an unprefixed attribute name is always null; - the interpretation of unprefixed attributes is determined by the element on which they appear. -- Richard Tobin, Namespaces 1.1 editor
Received on Thursday, 28 November 2002 13:30:17 UTC