Q: namespaces

[Hrvoje Somun]

<example xmlns:namespaceone="http://www.one.com" xmlns="http://www.one.com">
<check att1="one" att2="two" />
<check att1="one" namespaceone:att1="two" />
</example>


in my opinion line
<check att1="one" namespaceone:att1="two" />
is wrong (different namespaces for aributes of one element are not allowed)

right?

 

[Julian F. Reschke]

<example xmlns:namespaceone="http://www.one.com" xmlns="http://www.one.com">
<check att1="one" att2="two" />
<check att1="one" namespaceone:att1="two" />
</example>


in my opinion line
<check att1="one" namespaceone:att1="two" />
is wrong (different namespaces for aributes of one element are not allowed)

right?

No.

 

[Hrvoje Somun]

No.

so you think that this is well formed xml code?
<check namespaceone:att1="one" namespacetwo:att1="two" />

or is this only truth if one attribute is in default namespace?(first
example)

 

[Martin Boehm]

so you think that this is well formed xml code?
<check namespaceone:att1="one" namespacetwo:att1="two" />

or is this only truth if one attribute is in default namespace?(first
example)

It is true in both cases. Element nodes and attribute nodes can be
independently qualified with any namespace. If you omit a qalification
the attribute is in the namespace of its element, which is in turn in
the namespace of its parent.

Martin

 

[Martin Honnen]

It is true in both cases. Element nodes and attribute nodes can be
independently qualified with any namespace. If you omit a qalification
the attribute is in the namespace of its element, which is in turn in
the namespace of its parent.

I disagree with that, an attribute node has no namespace unless it has a
qualified name, it is not in the namespace of its element as you suggest.
Consider
http://www.w3.org/TR/REC-xml-names/#defaulting
which clearly says
Note that default namespaces do not apply directly to attributes.
This means if you have
<gods xmlns="http://www.gods.org/2003/gods" name="Kibo" />
then the attribute named "name" doesn't have a namespace although its
element has one.

 

[Martin Boehm]

I disagree with that, an attribute node has no namespace unless it
has a qualified name, it is not in the namespace of its element as
you suggest.

You are right.
But despite the fact that it obviously is as you said, this is not
logical to me. What is the point in not letting attributes inherit the
namespace of their parent if not otherwise stated?

Martin

 

[Richard Tobin]

But despite the fact that it obviously is as you said, this is not
logical to me. What is the point in not letting attributes inherit the
namespace of their parent if not otherwise stated?

An unprefixed attribute is in no namespace. But the interpretation of
an attribute in no namespace is determined by the element it is
attached to - it "belongs" to that element - so this is more a matter
of terminology and convention than practical importance.

-- Richard

 

[Martin Boehm]

An unprefixed attribute is in no namespace. But the interpretation of
an attribute in no namespace is determined by the element it is
attached to - it "belongs" to that element - so this is more a matter
of terminology and convention than practical importance.

So in the end it _is_ at least virtually (or interpretedly) in the
namespace of its parent (even though in a DOM it would not have its own
namespace-uri property set). So why does it explicitly _not_ inherit the
namespace, I don't understand the reason for this exception.

Martin

 

[Hrvoje Somun]

well yes i just realised that the example must be wrong because thare are
two attributes with same name in same element. so namespaces are not problem
here, mistake was in attribute name(corect me if i am wrong)

 

[Philippe Poulard]

So in the end it _is_ at least virtually (or interpretedly) in the
namespace of its parent (even though in a DOM it would not have its own
namespace-uri property set). So why does it explicitly _not_ inherit the
namespace, I don't understand the reason for this exception.

Martin

because it would be impossible for an attribute to be namespaceless if
it was defined within an unprefixed element bounded to the default namespace

<foo xmlns="foo-ns" bar="">
if bar inherited the foo-ns namespace, how to write a namespaceless
attribute ?
<f:foo xmlns:f="foo-ns bar="">
this could be done only by forcing user to use a prefix on such elements

it is simply a design choice : force user to specify a prefix either on
element or on attribute; w3c choose that if one need to bound an
attribute to a namespace, it must be done with a prefix

note: "namespaceless" means "in no namespace", don't know if it is
correct english
--
Cordialement,

///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------

 

[Martin Boehm]

well yes i just realised that the example must be wrong because thare
are two attributes with same name in same element.

No, that is allowed, too. They live in different namespaces. Hence they
do not have the same name, only the same local name in their respective
namespace.

Martin

 

[Martin Boehm]

[...] So why does it explicitly _not_ inherit the namespace,
I don't understand the reason for this exception.

because it would be impossible for an attribute to be namespaceless if
it was defined within an unprefixed element bounded to the default
namespace

[...]

it is simply a design choice : force user to specify a prefix either
on element or on attribute; w3c choose that if one need to bound an
attribute to a namespace, it must be done with a prefix

From my point of view: I define an element, put it into context by
giving it a namespace to live in... and then I am able to define
atributes virtually "not belonging" to the element but to no-one
instead?! What is the point defining out-of-context attributes by
default? Or, the other way round - what makes a namespaceless attribute
necessary? I mean, if it is interpreted as "belonging to" a qualified
element anyway.

note: "namespaceless" means "in no namespace", don't know if it is
correct english

Should be okay, but I am not a native speaker as well.

Martin

 

[Richard Tobin]

So in the end it _is_ at least virtually (or interpretedly) in the
namespace of its parent (even though in a DOM it would not have its own
namespace-uri property set). So why does it explicitly _not_ inherit the
namespace, I don't understand the reason for this exception.

The namespace spec *could* have said that an unprefixed attribute is
in the namespace of its element. This would have had an advantage for
attributes that can be used both on elements in "their own" namespace
and on other elements, such as

<rdf:description about="whatever">

and

<something rdf:about="whatever">

- both the "about" attributes would have been in the same namespace,
and writing XPaths to find them would be simpler.

Why wasn't this done? I *think* - and you'd need to ask the original
authors for a definitive answer - that they didn't want to imply that
the foo attribute on one element in a namespace was the same as the
foo attribute on another element. An appendix to the namespaces spec
talks of "per-element" namespaces or namespace partitions that
unprefixed attributes are in, but this idea was never carried through
into APIs and, crucially, XPath.

-- Richard

 

[Richard Tobin]

<example xmlns:namespaceone="http://www.one.com" xmlns="http://www.one.com">
<check att1="one" att2="two" />
<check att1="one" namespaceone:att1="two" />
</example>

in my opinion line
<check att1="one" namespaceone:att1="two" />
is wrong (different namespaces for aributes of one element are not allowed)

That's ok, because the attributes have different XML 1.0 names
(att1 and namespaceone:att1), and different XML+Namespaces expanded
names ({}att1 and {http://www.one.com}att1, using a common syntax).

However, if you'd had

<example xmlns:namespaceone="http://www.one.com" xmlns="http://www.one.com"
xmlns:namespacetwo="http://www.one.com">
<check namespaceone:att1="one" namespacetwo:att1="two" />
</example>

this would be illegal according to XML+Namespaces, since both attributes
have the same expanded name {http://www.one.com}att1.

-- Richard

 

[Philippe Poulard]

From my point of view: I define an element, put it into context by
giving it a namespace to live in...

That's optionnal; so if it may be optionnal that an element can be
namespaceless, then it must be the same for attributes.

and then I am able to define

atributes virtually "not belonging" to the element but to no-one
instead?! What is the point defining out-of-context attributes by
default? Or, the other way round - what makes a namespaceless attribute
necessary? I mean, if it is interpreted as "belonging to" a qualified
element anyway.

Attributes may belong to another namespace than its element, so it also
may be namespaceless whereas the element is not.
<f:foo xmlns:f="foo-ns" xlink:href="..." f:bar="..." bar="..."/>
Anyway, all these attribute "belong" to the same element.
--
Cordialement,

///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------

 

[Patrick TJ McPhee]

% The namespace spec *could* have said that an unprefixed attribute is
% in the namespace of its element. This would have had an advantage for
% attributes that can be used both on elements in "their own" namespace
% and on other elements, such as

[...]

% Why wasn't this done? I *think* - and you'd need to ask the original
% authors for a definitive answer - that they didn't want to imply that
% the foo attribute on one element in a namespace was the same as the
% foo attribute on another element.

It seems more likely that they didn't want to force xpath-like languages
to have prefixes on all their attributes, which would be the logical
outcome. Namespaces have less value for attributes than for elements,
and it's less cumbersome to deal with attributes in no name space than
to deal with attributes in a namespace.

 

[Richard Tobin]

It seems more likely that they didn't want to force xpath-like languages
to have prefixes on all their attributes, which would be the logical
outcome.

It wouldn't have to work that way. @foo could just mean "an attribute
foo in the namespace of its element". There might have to be a
special syntax for the case of an attribute in no namespace, but that
would be rarely needed since you wouldn't be able to have such an
attribute except on an element in no namespace, in which case @foo
would still match it.

-- Richard

 

[Martin Boehm]

It wouldn't have to work that way. @foo could just mean "an attribute
foo in the namespace of its element". There might have to be a
special syntax for the case of an attribute in no namespace, but that
would be rarely needed since you wouldn't be able to have such an
attribute except on an element in no namespace, in which case @foo
would still match it.

That is more or less what I wanted to point out. Maybe my wording was
not as clear as yours, I don't think I could have put it that way. ;-)

Martin

 

[Patrick TJ McPhee]

% In article <[email protected]>,
%
% >It seems more likely that they didn't want to force xpath-like languages
% >to have prefixes on all their attributes, which would be the logical
% >outcome.
%
% It wouldn't have to work that way.

No, but you're talking about the w3c. It _would_ work that way.