- 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:39 UTC