Re: XSLT (2) namespace safe i18n patterns
Thank you for your response.
The question I am trying to formulate is exactly about not relying on unstable namespace prefixes or finding a way to have a stable correspondence between localization codes and the corresponding namespaces. I am only trying to provide a flexible attribute i18n option. As you know, I have invested the last ten years in XML and XSLT, because I believe that XML is the universal information language and that XSLT is an ideal way of processing it. I am not blaming either, I am looking for a solution to a requirement and asking for support to figure it out. I did feel that the replies I got about going somewhere else somewhat meant that a solution could not be worked out on the platform, and I disagree with that. Maybe we can work out a solution, and I think we can, maybe we can think of ways to expand the platform a little if we cannot solve it otherwise, as we have done before, or maybe attribute i18n is truly impossible, as some seem to think already and I disagree with that. Maybe also my requirements for attribute i18n are unreal, but so far, from this end, it does not seem like it.
What I have now, for example, is a function (e.g. i18n:localize) returning a possibly empty string (e.g. the translated attribute value) and taking 3 parameters:
- source: the element node that has the attributes
- name: the local-name string for the attribute to localize
- lang: the selected localization code string
Currently using prefix matching (this is what needs improving/fixing) I can do something like:
<xsl:variable name="fullname" select="string-join(($lang, $name), ':')"/>
<xsl:value-of select="if (string(@*[name() eq $fullname])) then @*[name() eq $fullname] else @*[name() eq $name]"/></xsl:for-each>
That works fine and solves the application requirement and attribute i18n, as long as namespace prefixes still match localization codes, which is what I would like to add/change but am unsure as to the best way of doing it.
By the way, i18n is one case, but I can think of other cases where selecting what namespace to use at run-time could be useful, but to select namespace at run-time, some matching has to happen between the namespaces and some trigger or values, like in the case of the localization codes.
Thank you for your help and support.
It seems to us that adding attribute i18n, through namespaces can be naturally logical, flexible, appropriate for the task, and relatively simple.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format