[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT (2) namespace safe i18n patterns

Subject: Re: XSLT (2) namespace safe i18n patterns
From: ac <ac@xxxxxxxxxxxxx>
Date: Mon, 23 Nov 2009 11:04:53 -0500
Re:  XSLT (2) namespace safe i18n patterns
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

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.