xsl-list
[Top] [All Lists]

Re: Was: [xsl] mode and moved to Namespaces

2011-04-18 20:52:40
Hi Jirka,

Simply wrong?

I am not sure what is so simple about this.

Maybe you did not get the streaming content requirements which precludes, at least in principle, doing dynamic loading of each localization file. Any unpredictable number of languages need to be available, in a single transformation. Constant re-loading will not solve anything.

I do not mind "putting performance aside for a while", but not forever. It remains a requirement.

As for defining additional namespaces and changing the schema, what is wrong with doing it once, at design time, for all languages that will need to be supported? I never said I would like to constantly change the schema.

If the problem is simply to translate a document or set of documents from language A to Language B, I would load only the appropriate A/B translation dictionary. If on the other hand, if I am generating a portal with a thousand websites from a thousands StratML documents fetched from a thousand organizations in over 100 countries, and each document specifies the language it is using, and I need to translate all labels, section headers, menus and things in any of the languages that each organization decides, dynamically, as the documents are streaming in, I may have a different problem, and I have to say that your solution, however nice and practical it is for some problems, does not seem to solve this one.

Please do not think that I use namespaces because I think they are great, as I am sorry that they are not hierarchical (e.g. Flat), that consequently, they can force redundancy and duplication (e.g. Clumsy), that they are not optimized for performance (e.g. Inefficient), and that they are tricky to use and debug (e.g. Troublesome). It is just that given the requirements they seem to still provide the most appropriate solution.

Simply wrong is easy to say, but it is probably a relative thing like all others. Could you better explain to me why using namespaces would be "simply wrong", especially when they better solve the problem at stake?

You refer to my dictionary example, but not to my locator examples, with GML, for example, or the others. I get the feeling that the overall picture could mean something too.

Nevertheless, I understand your DocBook example, and agree with you that dynamic loading of smaller per language files, or datasets can provide interesting savings when everything does not have to be loaded together. I certainly also use and recommend that approach when applicable.

Thank you for your input and suggestion.

Regards,
ac



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ac wrote:

Overall, it is a trade of, but it seems that the namespace approach is
not only valid, it is more efficient, possibly by about 400% in terms of
space, in the given example, implying that it may be worth considering
and supporting.  The validity and support of version 1 was not
questioned or at stake.  The main issues was the support for version 2,
as well as the usefulness of namespaces, and the fact that 80 namespaces
in a stylesheet can be quite natural and not so out of bounds or silly.
Putting performance aside for a while it seems as a really poor design
to require change of schema and stylesheet for adding each new language.
This goes completely against good software engineering design.

Space could be saved by another means for example by storing each
localization in a separate file and loading them just on demand. For
example last year DocBook stylesheets changed from using one large
single localization file to dynamic loading of smaller per language
files and speedup was from 30-300% depending on document size and XSLT
engine used. Also about 10 MB of memory was saved during the transformation.

Weren't namespaces designed to be used?  If so, why avoid them at all
costs, especially in cases of natural conceptual namespaces?
There is nothing wrong with using namespaces, but, with respect, your
example of using namespaces is simply wrong.

                        Jirka

- --
- ------------------------------------------------------------------
   Jirka Kosek      e-mail: jirka(_at_)kosek(_dot_)cz      http://xmlguru.cz
- ------------------------------------------------------------------
        Professional XML consulting and training services
   DocBook customization, custom XSLT/XSL-FO document processing
- ------------------------------------------------------------------
  OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
- ------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2so8YACgkQzwmSw7n0dR6/aACfU2uWCc8holTZPQkbLBFuwVYr
cO8AmgJSyK7Vr8O0SxKWQpbFqDRFNfb2
=/1uR
-----END PGP SIGNATURE-----

--~------------------------------------------------------------------
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>
--~--