[tei-council] Attributes in no namespace

[Martin Holmes]

Hi Syd,

I'm willing to believe that lack of interest in attributes on the part 
of major sponsors of the XML spec is responsible for the design rules 
around attributes being a little flaky. But the odd thing is that 
they're flaky in a way which is not what you'd expect from neglect; the 
rules are both unintuitive and fairly clearly defined, as far as I can 
see. In the bit you quote below this seems to me unambiguous:

"The namespace name for an unprefixed attribute name always has no value."

That means it's the empty string, "", which is not the same as being
"in no namespace" at all; it means they share a namespace with all the 
other empty-string-namespace elements and attributes in the world.

I'm also not sure I agree with this:

>  if
> the XML Namespaces spec had been written such that attributes inherit
> the namespace of their parent element the same problem would occur.
> So this doesn't bother me.

Surely not? If TEI attributes were in the TEI namespace, and SVG 
attributes in the SVG namespace, then the difference between the two 
@end attributes would be clear and obvious in a document which uses both 
namespaces. I accept that context can differentiate the the definitions 
of identically-named attributes in a single namespace (as it does in the 
case of e.g. @type on various TEI elements); but in the case of two 
attributes whose difference is not one of nuance, but which are wholly 
unconnected with each other, and which we might wish to appear on the 
same element, there is surely a problem.

Imagine I have a mixed-namespace document which uses both TEI and XHTML 
elements (and I do, quite a lot; I frequently produce these as 
intermediate stages in rendering complex documents arising out of 
XQueries). Now imagine that my use of TEI @style is NOT CSS; I've 
decided I want to use some other style language. (I personally wouldn't 
do this, but it's perfectly well allowed by TEI.)

Now I may have XHTML @style attributes containing CSS, alongside TEI 
@style attributes containing  non-CSS language; and it wouldn't be 
surprising if they ended up being attached to the same element. If 
attributes were always in the namespace of their parent elements by 
default, and were defined as being in that namespace in their schemas, 
then I could do:

<tei:p tei:style="fancy" xhtml:style="font-style: italic">...</tei:p>

(In fact the prefix "tei:" on the first @style would be unnecessary it's 
just there for clarity.)

But there's no way I can actually do this, because the TEI's @style 
attribute is in the same empty-string namespace as the XHTML @style 
attribute. They are the same attribute, effectively. I could explicitly 
declare a new attribute that _is_ in the TEI namespace and is called 
"style", but that's antithetical to TEI conventions; custom elements and 
attributes are supposed to be declared in a NON-TEI namespace.

These are admittedly edge cases, but they're not too far removed from 
reality (and in fact I have really found myself wanting to use XHTML and 
TEI attributes on each other's elements in an intermediate pipeline 
representation of a document, and not been able to do it).

Perhaps it's not the TEI's business to grumble about the design of XML, 
but we were (long before my time) involved in the genesis of that 
design, and we are basing our entire infrastructure on it. Where it has 
weaknesses -- and I think this is one -- we need to be aware of them and 
make sure we don't misunderstand the situation (as the bit of Chapter 22 
in question does), and I think it would do no harm to find out why 
things are this way, and if, as you suggest, it's partly due to 
inattention or neglect, to lobby for a better situation in future versions.

Cheers,
Martin



On 13-12-30 08:00 PM, Syd Bauman wrote:
> Thoughts interspersed between extracts of Martin's post ...
>
>
>> That's what my ticket suggests:
>> <https://sourceforge.net/p/tei/bugs/631/>
>
> Righto. Just put my +1 on that.
>
>
>> ... although it's easy to distinguish between identical attributes
>> based on the namespace of their parent node in e.g. XPath, the fact
>> is that they are technically the same attribute in the context of a
>> multiple-namespace document, and their definitions are in conflict.
>
> But two attributes in a single-namespace document may have the same
> name, but because of context have different semantics. Moreover, if
> the XML Namespaces spec had been written such that attributes inherit
> the namespace of their parent element the same problem would occur.
> So this doesn't bother me.
>
>
>> ... we cannot import only an attribute from another specification
>> to use as a child [sic] of our own elements (unless it happens to
>> be explicitly defined with a namespace, such as e.g. @xlink:href);
>> we can only import elements which carry it. That means we were
>> unable to import and use the SVG @points attribute (for example)
>> into TEI; we had to create our own mirror of it, with the slight
>> risk that their definitions might diverge in the future.
>
> Wow. *Really* good point. I think I have to re-think my thinking on
> this issue.
>
>
>> This seems to me to be a fundamental design flaw, and I simply
>> don't understand it. Why did the designers of XML decide that
>> attributes don't inherit the namespace of their parent elements?
>
> My limited (mis-?)understanding from conversations w/ MSMcQ is that
>
> a) The idea that non-NS-qualified attributes are "in no namespace" is
>     not actually asserted in the Namespace spec.[1]
>
> b) No one really thought of this or suggested it; most the WG
>     members, or at least the big rich ones, were really only
>     interested in elements. If the idea of making attributes inherit
>     their parent elements namespace had been a requirement, the spec
>     probably would have never made it at all.
>
> c) In any case, namespaces in XML are so poorly defined he thinks
>     this issue is a bit like complaining that your boat is the wrong
>     color when it has a big hole in the bottom.
>
> Notes
> -----
> [1] It says:
>        Default namespace declarations do not apply directly to
>        attribute names; the interpretation of unprefixed attributes is
>        determined by the element on which they appear. ... The
>        namespace name for an unprefixed attribute name always has no
>        value. In all cases, the local name is local part (which is of
>        course the same as the unprefixed name itself).
>     I have to admit, I'm not sure right now what "determined by the
>     element on which they appear" means. But I'm pretty tired.
>