what does xmlns do exactly?

[gg9h0st]

i've looked XMLNS definition. and still have a question.

what if i define two defferent 'xmlns' for a namespace?

ex)

<nsa:aelement xmlns:nsa="a">
<nsa:aelement xmlns:nsa="b">
</nsa:aelement>
</nsa:aelement>

is it possible? and those two elements work as totaly different
elements?

[Joseph Kesselman]

what if i define two defferent 'xmlns' for a namespace?

<nsa:aelement xmlns:nsa="a">
<nsa:aelement xmlns:nsa="b">
</nsa:aelement>
</nsa:aelement>

Namespace prefix bindings are scoped. The descendants of the outer
element which reference the nsa: prefix understand it to mean the
namespace "a", EXCEPT where that's overridden by another definition as
you've done here. In this example the inner element and all its
descendants understand nsa: to mean the namespace "b".

Remember, the prefix is just a syntactic shorthand. What really carries
meaning is the combination of the URI the prefix is bound to plus the
localname following the prefix.

WARNING: These are NOT good namespace names. Namespace names should be
absolute URI references, according to the W3C. If you're going to use
something short and sloppy, in an example, you should at least use
"http://a" or something of that sort. (There was a major debate about
this in the W3C, due to a combination of sloppy wording in the first
draft of the namespace spec and some fuzzy thinking about whether there
was any useful way to interpret relative namespaces. The decision was
made to deprecate relative namespace URIs until and unless someone
convinces the W3C that they are both necessary and practical.)

>
is it possible? and those two elements work as totaly different
elements?

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Joseph Kesselman]

By the way, the "Namespaces in XML" specification, available from the
W3C's website, does spell out how namespace scoping works.

[Richard Tobin]

In article <45819442$1@kcnews01>,
Joseph Kesselman <ke************@comcast.netwrote:

>The decision was
made to deprecate relative namespace URIs until and unless someone
convinces the W3C that they are both necessary and practical.

Should relative namespace URIs be interpreted relative to xml:base?

(That's a rhetorical question, just in case there was any doubt.)

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Joseph Kesselman]

Richard Tobin wrote:

Should relative namespace URIs be interpreted relative to xml:base?

1) They shouldn't be used, period. The W3C has deprecated them. There
are absolutely NO promises about what will happen if you insist on
pointing this gun at your foot and pulling the trigger.

2) Namespace URIs are usually not interpreted in any case. A namespace
name is just that, a *NAME*, expressed in URI form mostly because we
already knew how to manage the value space of URIs so people didn't
accidentally use each others' values. There is absolutely NO promise
about whether a resource is actually available at that location or what
it might be if so. (The W3C's Semantic Web working group has been trying
to reach some sort of consensus on this, but as far as I know they still
haven't announced any conclusions.)

3) "Mu."

>
(That's a rhetorical question, just in case there was any doubt.)

-- Richard

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Richard Tobin]

In article <4581a292@kcnews01>,
Joseph Kesselman <ke************@comcast.netwrote:

>Should relative namespace URIs be interpreted relative to xml:base?

>1) They shouldn't be used, period. The W3C has deprecated them.

My rhetorical question was meant to suggest a reason for them to
continue to...

>2) Namespace URIs are usually not interpreted in any case.

They're not dereferenced, certainly.

>A namespace
name is just that, a *NAME*, expressed in URI form

Right, but would that name be combined with the current base URI?
Would this be the root element of an XSLT stylesheet?

<stylesheet xmlns="XSL/Transform" xml:base="http://www.w3.org/1999"
version="1.0">

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Joseph Kesselman]

Richard Tobin wrote:

>>>Should relative namespace URIs be interpreted relative to xml:base?

1) They shouldn't be used, period. The W3C has deprecated them.

My rhetorical question was meant to suggest a reason for them to
continue to...

Good enough. I'm still surprised how many people DID try to argue that
the meaning of <thisCouldKillYou:safetyPolicyshould change when they
moved the document from one directory to another

>>2) Namespace URIs are usually not interpreted in any case.

They're not dereferenced, certainly.

Better phrasing; thanks for the correction.

Right, but would that name be combined with the current base URI?
Would this be the root element of an XSLT stylesheet?
<stylesheet xmlns="XSL/Transform" xml:base="http://www.w3.org/1999"
version="1.0">

No. Namespace names are just literal strings whose syntax is required to
be that of absolute URI references. Absolutely no URI handling magic is
applied to them.

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Richard Tobin]

In article <4581d1a3$1@kcnews01>,
Joseph Kesselman <ke************@comcast.netwrote:

>Right, but would that name be combined with the current base URI?
Would this be the root element of an XSLT stylesheet?
<stylesheet xmlns="XSL/Transform" xml:base="http://www.w3.org/1999"
version="1.0">

>No. Namespace names are just literal strings whose syntax is required to
be that of absolute URI references. Absolutely no URI handling magic is
applied to them.

They *are*, but I was considering the hypothetical case. Combining
namepace names with base URIs is what at least one company who argued
for relative namespace URIs wanted. In particular, they wanted
relative namespace URIs in different documents to be distinct by
virture of being relative to different URIs.

This was one of the few case where the W3C held a ballot to resolve
the issue; as we all now know the result was to deprecate relative
namespace URIs and declare that future specs would "define no
interpretation".

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Joseph Kesselman]

Richard Tobin wrote:

This was one of the few case where the W3C held a ballot to resolve
the issue

And I think consensus, now that we've all had time to think about it is
that the majority decision was, in fact, the right decision. (Remember,
I was there too. One of the few times I've found myself in a
head-to-head with Tim B-L.)

Bringing up a hypothesis which has already been considered and
discredited without clarifying that status strikes me as more confusing
than helpful. XML Namespaces "is what it is and that's all what it is";
let's not distract folks with excursions into why the alternatives are
broken unless they're specifically interested in that history. If pigs
had wings, they'd be pigeons.

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Richard Tobin]

In article <4581e3b0$1@kcnews01>,
Joseph Kesselman <ke************@comcast.netwrote:

>Bringing up a hypothesis which has already been considered and
discredited without clarifying that status strikes me as more confusing
than helpful.

I was just giving an illustration of why it was unlikely that the
W3C would ever consider them practical, in response to your original
comment:

>The decision was
made to deprecate relative namespace URIs until and unless someone
convinces the W3C that they are both necessary and practical.

Relative namespace URIs are just a can of worms.

I *did* say it was a rhetorical question!

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Joseph Kesselman]

I *did* say it was a rhetorical question!

Good enough. We can chalk it up to "agreeing at the tops of our voices",
then. <grin/>

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden