createElementNS

Discussion in 'XML' started by Tom Anderson, Jun 23, 2008.

  1. Tom Anderson

    Tom Anderson Guest

    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

    --
    Mathematics is the door and the key to the sciences. -- Roger Bacon
    Tom Anderson, Jun 23, 2008
    #1
    1. Advertising

  2. * 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 · mailto: · 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/
    Bjoern Hoehrmann, Jun 23, 2008
    #2
    1. Advertising

  3. Tom Anderson

    Tom Anderson Guest

    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
    Tom Anderson, Jun 24, 2008
    #3
  4. * 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 · mailto: · 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/
    Bjoern Hoehrmann, Jun 24, 2008
    #4
  5. 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.
    Joseph J. Kesselman, Jun 24, 2008
    #5
  6. Tom Anderson

    Tom Anderson Guest

    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!
    Tom Anderson, Jun 24, 2008
    #6
  7. Tom Anderson

    Tom Anderson Guest

    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!
    Tom Anderson, Jun 24, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nicolas VanOrton
    Replies:
    0
    Views:
    398
    Nicolas VanOrton
    Mar 8, 2005
  2. James Black
    Replies:
    10
    Views:
    276
    Thomas 'PointedEars' Lahn
    May 25, 2006
  3. Prasanna

    document.createElementNS on IE...

    Prasanna, Aug 8, 2007, in forum: Javascript
    Replies:
    3
    Views:
    313
    David Mark
    Aug 9, 2007
Loading...

Share This Page