createElementNS

Tom Anderson · Jun 23, 2008

Hi,

I don't know if this is the appropriate newsgroup for questions about DOM,
so feel free to tell me to get lost.

Anyway, i'm puzzling over why createElementNS takes a qualified name,
rather than a local one. I thought the sole function of a qualified name
in XML is to enable the parser to figure out which namespace an element
belongs to, a sort of macro function that means we don't have to write
things like

<http://www.w3.org/1999/xhtml:p>This is a paragraph that looks like it is
sticking its tongue out.</http://www.w3.org/1999/xhtml:p>

Not that that would be legal, but i hope you see what i mean.

I mean, i can write this:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:foo="http://www.w3.org/1999/xhtml">
<foo:body>
</foo:body>
</html>

And it works, right? What matters is the namespace, not the prefix that
happens to be in use.

So why do i need to specify a prefix, by giving a qualified name, in
createElementNS? And does it need to be the same as the prefix in use in
the rest of the document? For instance, if i have a document:

<foo:root xmlns:foo="http://example.invalid/fooNS">
<foo:content/>
</foo:root>

And i do a createElementNS("http://example.invalid/fooNS", "bar:content"),
and appendChild it to the root element, will that 'work'? Do the rules say
that the appended element should behave just like the parsed one? I
realise that DOM calls which inspect the prefix or nodeName attributes of
the element will see the 'bar' prefix, but can i rely on most code (define
that how you will) doing the right thing (ditto)?

The production for qualified names in the namespace spec says that the
prefix is optional; does that mean i can omit it, saying
createElementNS("http://example.invalid/fooNS", "content"), and it will
work?

Should i, for theoretical, practical, or aesthetic reasons, attempt to use
the same prefix as used in the rest of the document? Is there a convenient
way to do that? I can't immediately see any such thing in the DOM spec.

As a wider question, why does the DOM even make namespace prefixes
available? As a kind of backwards compatibility?

Thanks in advance for any input,
tom

Bjoern Hoehrmann · Jun 23, 2008

* Tom Anderson wrote in comp.text.xml:

Anyway, i'm puzzling over why createElementNS takes a qualified name,
rather than a local one.

Because you may want to use a specific prefix rather than the default
namespace when the document is serialized, for example, because you are
used to have "xsl:" in front of your XSLT element names.

So why do i need to specify a prefix, by giving a qualified name, in
createElementNS? And does it need to be the same as the prefix in use in
the rest of the document?

You do not have to specify a prefix, the local name alone will do fine.
You can use any prefix (provided it is syntactically valid) you like, it
will be corrected if necessary when saving the document. The DOM ignores
the prefixes for most other operations.

Should i, for theoretical, practical, or aesthetic reasons, attempt to use
the same prefix as used in the rest of the document? Is there a convenient
way to do that? I can't immediately see any such thing in the DOM spec.

I am not entirely sure I understand the question, but DOM Level 3 Core
has various methods for namespace lookup that should help here. Usually,
if you have to read the prefix from the document, it does not matter so
much.

As a wider question, why does the DOM even make namespace prefixes
available? As a kind of backwards compatibility?

I've already mentioned control over serialization, another one would be
their significance, e.g., to use prefixes in content (like an attribute
value that takes an XPath expression) you have to read or manipulate the
prefixes of the namespace declarations (xmlns:example attributes).

Tom Anderson · Jun 24, 2008

* Tom Anderson wrote in comp.text.xml:

Because you may want to use a specific prefix rather than the default
namespace when the document is serialized, for example, because you are
used to have "xsl:" in front of your XSLT element names.

According to the XSLT spec:

http://www.w3.org/TR/xslt#xslt-namespace

"XSLT stylesheets are free to use any prefix, provided that there is a
namespace declaration that binds the prefix to the URI of the XSLT
namespace."

So, at least according to the spec, that's not a situation where the
prefix itself is important. I have no idea if processors follow this part
of the spec in real life.

And, moreover, when you serialise, isn't it the job of the serialiser to
apply the appropriate prefixes? If prefixes were expunged from the DOM
tree, they could simply be an encoding issue, like numeric character
references. I was going to say "like entities", but i see that those are
also not necessarily resolved by the parser. Yikes.

You do not have to specify a prefix, the local name alone will do fine.
You can use any prefix (provided it is syntactically valid) you like, it
will be corrected if necessary when saving the document. The DOM ignores
the prefixes for most other operations.

Okay, great, that's what i was hoping!

I am not entirely sure I understand the question, but DOM Level 3 Core
has various methods for namespace lookup that should help here. Usually,
if you have to read the prefix from the document, it does not matter so
much.

Fair enough.

I've already mentioned control over serialization, another one would be
their significance, e.g., to use prefixes in content (like an attribute
value that takes an XPath expression) you have to read or manipulate the
prefixes of the namespace declarations (xmlns:example attributes).

XPath is an interesting case, and one which is relevant to my interests,
actually. XPath does its comparisons on the basis of the namespace URI,
rather than the namespace prefix, but it uses the namespace declarations
in the target document to map prefixes to URIs. So, the expression:

//foo:qux

Selects different things in these two documents:

<foo:qux xmlns:foo="http://ns.invalid/outer">
<bar:qux xmlns:bar="http://ns.invalid/inner">
</bar:qux>
</foo:qux>

<bar:qux xmlns:bar="http://ns.invalid/outer">
<foo:qux xmlns:foo="http://ns.invalid/inner">
</foo:qux>
</bar:qux>

This strikes me as being the Wrong Thing to do, somehow.

The Right Thing would probably be to give XPath its own namespace mapping,
so you'd say something like (in COBOL!):

ADD NAMESPACE "http://ns.invalid/outer" TO XPATH WITH PREFIX "foo"
EVALUATE XPATH QUERY "//foo:qux" ON DOCUMENT doc

But this would be a pain to use.

Anyway, thanks for your help, Bjoern!

tom

Bjoern Hoehrmann · Jun 24, 2008

* Tom Anderson wrote in comp.text.xml:

So, at least according to the spec, that's not a situation where the
prefix itself is important. I have no idea if processors follow this part
of the spec in real life.

And, moreover, when you serialise, isn't it the job of the serialiser to
apply the appropriate prefixes? If prefixes were expunged from the DOM
tree, they could simply be an encoding issue, like numeric character
references. I was going to say "like entities", but i see that those are
also not necessarily resolved by the parser. Yikes.

Yes, it is a matter of personal preference, not technical necessity; the
serializer would have a hard time to pick the right prefixes (according
to your personal preferences), and if the prefixes are not stored in the
tree, you could not load and save a document without modification of the
prefixes at least in some cases.

XPath is an interesting case, and one which is relevant to my interests,
actually. XPath does its comparisons on the basis of the namespace URI,
rather than the namespace prefix, but it uses the namespace declarations
in the target document to map prefixes to URIs.

XPath expressions are evaluated in an evaluation context that has, among
other things, a set of namespace declarations. Where those come from is
not pre-determined by the XPath specification, and it is rare that the
prefixes from the target document are used (usually, like in XSLT, you
use the ones from the source document, or define them independently like
in DOM Level 3 XPath).

Joseph J. Kesselman · Jun 24, 2008

Speaking as one of the folks who was involved in developing that API:

The DOM can store the prefix, so we give you the ability to provide the
prefix. Ideally, no properly-written XML application should care about
which prefix was used... but some folks want to pass the prefix through
to help improve human-readability of the name (as a hint to the
serializer or to other display routines), and this gives us a way of
doing so.

If you want an in-depth discussion of this, see DOM Level 3's discussion
of namespace normalization during serialization (or when explicitly
requested).

But barring a sloppily-written application, it *should* be safe to just
provide the localname and the correct namespace URI (ie, the
semantically meaningful information) and let downstream code work
prefixes out properly if and when they're relevant.

Tom Anderson · Jun 24, 2008

* Tom Anderson wrote in comp.text.xml:

Yes, it is a matter of personal preference, not technical necessity; the
serializer would have a hard time to pick the right prefixes (according
to your personal preferences), and if the prefixes are not stored in the
tree, you could not load and save a document without modification of the
prefixes at least in some cases.

Yes, if "right prefixes" means something, this would be a potential
problem. I guess my solution would be for there to be some way of
collecting prefix-to-namespace mappings from the parser through a side
channel, eg a namespace listener, and then have a way to them into the
serializer. The knowledge about the prefixes could thus be preserved, but
wouldn't contaminate the document tree.

XPath expressions are evaluated in an evaluation context that has, among
other things, a set of namespace declarations. Where those come from is
not pre-determined by the XPath specification, and it is rare that the
prefixes from the target document are used (usually, like in XSLT, you
use the ones from the source document, or define them independently like
in DOM Level 3 XPath).

Ah, okay. I guess i misunderstood that once again! I'm doing XPath queries
programmatically, and we define the relevant namespace mappings
programmatically too. I'd assumed that it was also possible to pick them
up from the document being queried, but i guess not. Good.

I'm not sure i like the idea of picking them up from namespace
declarations in the containing document, though. I'd be happier if it was
explicit, although i can see how this could be awkward.

tom

Tom Anderson · Jun 24, 2008

Speaking as one of the folks who was involved in developing that API:

Oh crumbs, now i'm in trouble!

The DOM can store the prefix,

That's what i think is unfortunate, but given that it's true ...

so we give you the ability to provide the prefix.

.... that was absolutely the right thing to do.

Ideally, no properly-written XML application should care about which
prefix was used... but some folks want to pass the prefix through to
help improve human-readability of the name (as a hint to the serializer
or to other display routines), and this gives us a way of doing so.

Right. Those uses are fair enough; i just wish they could have been
relegated to a side-channel, or to a namespacePrefixMap in Document or
something. This is not a criticism of your work!

If you want an in-depth discussion of this, see DOM Level 3's discussion
of namespace normalization during serialization (or when explicitly
requested).

Will do. That'll be a nice relaxing start to the day tomorrow!

But barring a sloppily-written application, it *should* be safe to just
provide the localname and the correct namespace URI (ie, the
semantically meaningful information) and let downstream code work
prefixes out properly if and when they're relevant.

Wonderful.

I'll mention that i'm working with XHTML, which is a wonderful topsy-turvy
world where "must" is considered advisory, and "should", well, the less
said about it the better ...

Anyway, thanks for your authoritative input.

tom

Loop through record in datareader in aspx for textbox other item	1	Sep 26, 2023
SVG not full width and space	0	Sep 15, 2023
XHTML - how extend/create ELEMENT body in my DTD?	0	Oct 29, 2019
JS exercise ''find the mistake'' not understood well	4	Apr 4, 2024
How do I hide the modal after 5 seconds?	4	Jun 1, 2023
SVG & namespaces	4	Dec 4, 2008
Responsive width SVG image with fixed height rectangle at left and bottom - see my pen	0	Nov 26, 2022
XHTML Modularization: Creating XML schema for mixed custom tags andXHTML	0	May 9, 2008

createElementNS

Tom Anderson

Bjoern Hoehrmann

Tom Anderson

Bjoern Hoehrmann

Joseph J. Kesselman

Tom Anderson

Tom Anderson

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads