createElementNS

06-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

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

>

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

--
Mathematics is the door and the key to the sciences. -- Roger Bacon

06-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).
--
Björn Höhrmann · private.php?do=newpm&u= · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

06-24-2008

On Mon, 23 Jun 2008, Bjoern Hoehrmann wrote:

> * 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.

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.

>> 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.

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

>> 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.

Fair enough.

>> 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).

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

--
Gatsos are a stealth tax on motorists in the same way that city centre
video cameras are a stealth tax on muggers and DNA testing is a stealth
tax on rapists. -- Guy Chapman

06-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.

>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).
--
Björn Höhrmann · private.php?do=newpm&u= · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

06-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.

06-24-2008

On Tue, 24 Jun 2008, Bjoern Hoehrmann wrote:

> * 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.
>>
>> 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.

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 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).

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

--
Curse me, God, for making you this way!

06-24-2008

On Tue, 24 Jun 2008, Joseph J. Kesselman wrote:

> 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

--
Curse me, God, for making you this way!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
document.createElementNS on IE...	Prasanna	Javascript	3	08-09-2007 06:34 AM
using document.createElementNS or document.createElement	James Black	Javascript	10	05-25-2006 11:15 AM
createElementNS and attributes with default values	Nicolas VanOrton	XML	0	03-08-2005 12:34 PM