Hi Michael,
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:for-each select="$source">
<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.
Cheers,
ac
It seems to us that adding attribute i18n, through
namespaces can be naturally logical, flexible, appropriate
for the task, and relatively simple.
My immediate reaction is that this is a curious and rather unusual use of
namespaces, but it could be made to work.
The only partly missing
piece is namespace and/or prefix safety, at matching time, in
the matching function, in XSLT.
I'm not sure I fully understand what you mean by "namespace and/or prefix
safety", but it seems to me that your design is over-reliant on namespace
prefix matching and that can't be right.
Before we question XML's ability to be the universal
information language, can we still try to use XSLT to meet
these "real world"
requirements? Do you already think that it is impossible?
Of course it's possible. But I'm not sure that this particular way of doing
it is sound. You seem to be suggesting "My design is the only possible
design, and I can't make it work, therefore XML is deeply flawed." The fault
is in the premise...
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--