W3C home > Mailing lists > Public > public-xhtml2@w3.org > May 2008

reparing XML Namespaces without breaking existing content

From: Robert J Burns <rob@robburns.com>
Date: Wed, 28 May 2008 18:08:35 +0000
Message-Id: <AFB93528-A1CA-49EC-B342-5A8CD2B4080B@robburns.com>
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:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:48 GMT