I don't understand why this situation is any different to having an attribute
with a namespace prefix that cannot be used since the prefix is already bound
on the same element to a different namespace URI. In both cases the XDM
shouldn't care, because the prefix is irrelevant to the actual name of the
attribute (the namespace URI/local name pair).

In my opinion this situation is a serialisation issue, and should be dealt with
during serialisation. I think the obvious solution is to make up a namespace
prefix for the attribute in both cases - but an alternative solution is to
raise an error.

Namespace fixup is not the responsibility of the serializer: the XDM model
contains the tree structure *after* fixup has been applied. This enables anyone
accessing an XDM tree to be confident that it will satisfy basic XML rules such
as names being valid, and no element having two attributes with the same name.
The rule that an attribute in a namespace always has a prefix falls into the
same category.

>In both cases the XDM
shouldn't care, because the prefix is irrelevant to the actual name of the
attribute (the namespace URI/local name pair).

The name of the attribute is not a namespace URI/local name pair: it is a
triple that also includes a prefix: see section 3.3.3 ("In this Data Model,
therefore, the value space for qualified names contains a local-name, an
optional namespace URI, and an optional prefix.")

The prefix is ignored when comparing two names, but it is visible to
applications via functions such as name(). It's important from a usability
perspective that name() applied to a node should return the same string that
you see when serializing the node, since it is often used in messages and
similar output.

>I don't understand why this situation is any different to having an attribute with a namespace prefix that cannot be used

It isn't any different, that's the whole point. In both cases, namespace fixup
should ensure that the data model is correct and consistent. The only
difference is that we already have constraints saying that if the attribute has
a prefix then the prefix must be in-scope on the containing element; we don't
currently have a constraint saying that if it has a URI then it must have a
prefix.

I agree with Mike.

The WGs decided to accept the proposed solution in the description as the fix
for this bug at the Joint telcon 329 of 2007-05-08.