Well, passing lexical QNames across interfaces is definitely a bad idea unless
you can be sure that both sides of the interface know the namespace context
(that is, the set of prefix-URI bindings). Without a namespace context, a
lexical QName is meaningless.
Michael Kay
Saxonica
On 22 Jul 2020, at 01:23, Ihe Onwuka <ihe(_dot_)onwuka(_at_)gmail(_dot_)com>
wrote:
On Tue, Jul 21, 2020 at 7:48 PM Michael Kay <mike(_at_)saxonica(_dot_)com
<mailto:mike(_at_)saxonica(_dot_)com>> wrote:
If the QNames are names of elements in the source document, then you
shouldn't be calling name() to get the lexical QName, and then calling
xs:QName to turn it back into an xs:QName value, because that loses
information (specifically, the namespace bindings that were in scope in the
source document). Instead, you should use the node-name() function to get the
name as an xs:QName value in the first place.
You may have mistook $name for the name(), I am not calling the name()
function however that is useful information.
I may have misunderstood what's going on here,
All that function does is get the local name from a parameter which is
either already an xs:QName or a string that will be cast to an xs:QName.
There is not much to it beyond wanting to use XPath name functions rather
than string hacking on names.
but I think this is the heart of the issue: if you're going to manipulate
QNames, then you need to get them out of lexical format and into structured
xs:QName format as early as possible, while the original namespace bindings
are still known.
Michael Kay
Saxonica
On 21 Jul 2020, at 15:02, Ihe Onwuka <ihe(_dot_)onwuka(_at_)gmail(_dot_)com
<mailto:ihe(_dot_)onwuka(_at_)gmail(_dot_)com>> wrote:
Every element in my input doc is in one of 5 namespaces that I have
declared globally in the stylesheet. However the stylesheet as written never
explicitly references any of the 5 namespaces so I would like to genericize
it by doing away with the namespace declarations.
However if I remove any one of the namespaces I get this error.
Error at char 79 in expression in xsl:sequence/@select on line 14 column 118
of ***.xsl:
FONS0004 Namespace prefix {jx} has not been declared
at function local:localizedName on line 12 of ***.xsl:
Here is the function local:localizedName which is designed to return a
local name from a QName or a string.
<xsl:function name="local:localizedName" as="xs:string?">
<xsl:param name="name"/>
<xsl:sequence select="local-name-from-QName(if ($name instance of
xs:QName) then $name else xs:QName($name))"/>
</xsl:function>
It seems that casting anything as QName mandates that the namespace prefix
in whatever is being cast must be declared , even if it's not explicitly
referenced.
e.g xs:string(xs:QName($someName)) will fail if $someName contains 'ab:cde'
and you haven't declared the ab prefix anywhere (even if you don't otherwise
use it).
In which case my goal is better achieved by eradicating the QNames and
resorting to string manipulation to extract the local part of the name.
Comments, observations, corrections please.
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
<http://saxon.markmail.org/>
saxon-help(_at_)lists(_dot_)sourceforge(_dot_)net
<mailto:saxon-help(_at_)lists(_dot_)sourceforge(_dot_)net>
https://lists.sourceforge.net/lists/listinfo/saxon-help
<https://lists.sourceforge.net/lists/listinfo/saxon-help>
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--