- From: Robert J Burns <rob@robburns.com>
- Date: Wed, 28 May 2008 18:08:35 +0000
- To: public-xml-core-wg@w3.org
- Cc: public-xhtml2@w3.org, www-tag@w3.org, "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>, "Gregory J. Rosmaita" <oedipus@hicom.net>
Hello W3C community, [Gregory Rosmaita recommended I send this suggestion to these lists.] There has recently been extended discussion of namespaces within the HTML WG and other WGs and I'd like to suggest these are some issues that can be fixed even now in a backwards and forwards compatible manner. What I'm suggesting is this: • unprefixed attributes should be added to parent elements in the same namespace as the parent element (unprefixed attributes are then understood as scoped to the namespace of their parent element) • DOM manipulation of attributes should ensure that when methods do not specify a namespace, the method should infer the namespace of the parent element of the attribute (attributes without parent elements and without a namespace specified would be in the null namespace) • CSS3 selectors (still in draft status) would be reconceptualized to match the newly repaired XML namespaces so that using the example from • Similar changes would need to be made for XPath, XQuery and any other specification that assumes unprefixed attributes in a compound document are in the null namespace. The key here is to • treat unprefixed attributes as scoped to the namespace of their parent element • ensure DOM methods that manipulate attributes cause attributes without a namespace specified to inherit the namespace of the parent element to which they're attached • re-conceptualize the other recommendation/specifications that deal with namespaces to change their unprefixed attribute treatment to one of a scoped namespace for the attribute and not a null namespace for the attributes. a CSS3 draft example[1]: > > CSS examples: > > @namespace foo "http://www.example.com"; > [foo|att=val] { color: blue } > [*|att] { color: yellow } > [|att] { color: green } > [att] { color: green } > > The first rule will match only elements with the attribute att in > the "http://www.example.com" namespace with the value "val". > > The second_AND FOURTH_ rule will match only elements with the > attribute att regardless of the namespace of the attribute > (including no declared namespace). > > The _THIRD RULE_ will match only elements with the attribute att > where the attribute is not declared to be in a namespace. These CSS selectors could be changed slightly to be more consistent with the current CSS3 selectors draft, however, I think making [att] select attributes regardless of namespace will break less content and confuse fewer authors than making [att] select only on attributes whose namespace is the same as their parent (which would be another way to go more consistent with the current CSS3 draft). Making these changes would mean the repair of XML namespaces. It would also mean that virtually no existing content would break. I really don't see any downsides, except the few DOM authors effected by iteration looking for null namespace attributes that are now no longer null, however in that case the author should probably already be looking for both unprefixed and prefixed attributes with the parent elemnet’s namespace for thoroughness (which is the problem this fixes). The upside is that authors can now fully mix vocabularies — including attributes where appropriate — and not end up with those attributes in two separate namespaces though derived from the same vocabulary (null and the document’s specified namespace for the vocabulary). This would have one drawback caused by needing to provide legacy compatibility, but it is a small or insignificant one as far as I can tell. There would be no way to use the DOM to create null namespaced attributes and then attach those attributes to non-null namespaced elements. So this would be made impossible: <root-element xmlns='http://www.example.com/first-vocabulary' xmlns:second='http://www.example.com/second-vocabulary' xmlns:third='http://www.example.com/third-vocabulary' xmlns:null='' > ... <an-element null:attribute='value' attribute='value' /> <third:another-element second:attribute='value' attribute='value' > </third:element> ... </root-element> In this example, the 'another-element' element is in the 'third- vocabulary' namespace. Likewise the unprefixed 'attribute' attribute is also in the 'third-vocabulary' namespace. However, the previous element 'an-element' is in the default namespace ('first-vocabulary'). The 'null' prefixed attribute is in the null namespace. Under this proposal to fix XML namespace, there would be no way to use the DOM to put such a null namespaced attribute on an element that was not itself in the null namespace. I don't think that is a serious problem because I don't think authors should be creating compound documents with universal attributes set to be in the null namespace. If it was considered a serious problem, then I think a way could be found for non-legacy implementations to accomplish this. Take care, Rob [1]: <http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#attrnmsp>
Received on Wednesday, 28 May 2008 18:09:33 UTC