Namespace prefixes when using path() extensio

  • Antony Scerri
    Antony Scerri


    I had a quick question regarding the use of the path extension function. I'm
    currently using this with the last release of SaxonB, so it may be something
    which has been changed/fixed later on although I suspect not. When calling
    this extension with an element defined in a namespace through the use of a
    default namespace declaration (so no explicit prefix) this function returns an
    xpath without any prefix on the element names even when there is a matching
    one declared in the current context (I'm doing this within XQuery). From the
    source it looks like this is intentional, there is a comment to the effect
    that the original prefix will be preserved and so I assume when there isnt one
    it will not include one.

    I'm intending on using this to store information in an XPointer type way for
    later use to resolve back to the element, one such use case may be passing
    this back to the evaluate extension. However this isnt going to work without
    the namespace prefixes being added to the path for it to work in the context
    of the current document on the assumption they will be declared equivalent at
    the point of evaluation.

    So I'm curious as to whether this is a bug, or something for which this
    function wasnt intended, or have I missed an option/configuration somewhere.



  • Michael Kay
    Michael Kay

    The main reason there isn't a similar path() function in the standard library
    is the difficulty in finding a good answer to this question. The current
    saxon:path() function is useful for diagnostic use, but it doesn't create a
    path expression that can be put back into saxon:evaluate() to get back the
    original node.

    This use case inspired a new addition to XPath 3.0, the ability to use
    "EQNames" in the form "uri":local wherever a QName can be used. Your mail
    reminds me that we need a standard function to generate paths in that form -
    I've put this in a requirements bug entry so it will appear on the WG agenda.

    Michael Kay

  • David Lee
    David Lee

    Amazing. Just this morning I hit he problem of having to represent a path in
    a way I could both use it as a XSLT match path OR deconstruction it into the
    list of parent/child component qnames. Until this morning I was ignoring
    namespaces and was just doing name/name/name/name ... works great without
    namespaces, but now I need to put in the namespaces.

    I guess I'm too early for XPath 3 ... but please put in my vote for a standard
    way to do this !
    Maybe I'll use Clark notation for now and decode it later (?) or maybe use
    prefixes but then I have to declare the namespaces appropriately.


  • Antony Scerri
    Antony Scerri

    Thanks for the response. Namespaces and handling of prefixes have always
    caused some issues. I would think a simple extension that recognised any
    namespace declarations and their associated prefixes (in either the XSLT or
    XQuery contexts) could then put those prefixes on the XPaths, it would then
    match up when executing a call to evaluate.

    I checked the documentation and the saxon:path() documents does have the
    following which may need ammending slightly:

    "The resulting string can be used as input to the evaluate() function,
    provided that any namespace prefixes it uses are declared."

    This doesnt quite cover the case where the document doesnt use prefixes, and
    doesnt set any default namespace in the query context, not that it would still
    cover the case where multiple default namespaces were used in a document down
    the path to a given node.

    I'll have a go at another extension which produces paths using existing
    namesapce declaration in the XQuery to apply prefixes as that should meet my
    needs for the time being.