I'm finding this discussion puzzling. Given that we have QNames for the
values of the name attribute es on <element> and <attribute>, I cannot
imagine why one would not allow them for the value of the <name> element.
The TREX spec allows them (see
http://thaiopensource.com/trex/spec.html#Namespace_Expansion). The current
spec allows them because it transforms the name attribute into a name
element before doing QName expansion. Thus it adds no complexity to the
spec to allow this. As far as the implementation, it adds exactly 1 line
of code (or at least makes 1 line of code more complex).
I also don't understand the comment "Global attributes require QNames".
How so?
<attribute name="xml:lang">
<data type="language"/>
</attribute>
works just fine, just as one would expect.
--On 17 July 2001 10:42 -0700 Kohsuke KAWAGUCHI
<> wrote:
>
>
>> > > <name>string</name>
>> > >
>> > > should read
>> > >
>> > > <name>QName</name>
>> >
>> > really?
>> >
>> > Do we really want to allow QNames for <name>?
>>
>> I would like to allow them, since global attributes (e.g., xml:lang)
>> require <name> always.
> Yet another QName .... Ouch!
>
> "<name>xml:lang</name>" would be certainly easy to write,
> and consistent to the name attribute, since the name attribute allows
> QName.
>
> But from another point of view, you can always write as
>
> <name ns="http://www.w3.org/1998/XML">lang</name>
>
> to achieve the same result.
>
>
> regards,
> --
> Kohsuke KAWAGUCHI +1 650 786 0721
> Sun Microsystems
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
>
>
