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>
--~--
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Was: [xsl] mode and moved to Namespaces, (continued)
- Re: Was: [xsl] mode and moved to Namespaces, Jirka Kosek
- Re: Was: [xsl] mode and moved to Namespaces,
ac <=
- Re: Was: [xsl] mode and moved to Namespaces, Michel Hendriksen
- Re: Was: [xsl] mode and moved to Namespaces, Jirka Kosek
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Jirka Kosek
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Abel Braaksma
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Abel Braaksma
- Re: Was: [xsl] mode and moved to Namespaces, ac
- Re: Was: [xsl] mode and moved to Namespaces, Wendell Piez
|
|
|