[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Hi Jirka,
One of the first performance consideration issue is memory usage. There is a lot happening in the application and the number of supported languages could be high. How to keep everything loaded is not an issue.
If our main requirement was elegance, we would probably have lots of elements and attributes and metadata attached to the dictionary, and the dictionary would not be designed only for quick translation to a high number of languages in tight space, but for vocabulary, definitions, synonyms, antonyms, syntactic analysis, semantics management, and translation. In fact, we do that in other sections of the application. That is not the problem we are trying to solve here.
The reality is that this dictionary is used for translation and
the translated term is effectively returned by a key-based query that is more like
key('translator', $target, $dic)/@*[starts-with(name(), $lang)]
It must be good to know what is right from what is wrong,
especially with an absolute perspective.
I have to admit that I have always had some disbelief about absolute beliefs,
but I will keep an open mind, at least just in case.
Re: Was: [xsl] mode and moved to Namespaces
Subject: Re: Was: [xsl] mode and moved to Namespaces From: ac <ac@xxxxxxxxxxxxx> Date: Tue, 19 Apr 2011 15:32:18 -0400 |
Hi Jirka,
One of the first performance consideration issue is memory usage. There is a lot happening in the application and the number of supported languages could be high. How to keep everything loaded is not an issue.
If our main requirement was elegance, we would probably have lots of elements and attributes and metadata attached to the dictionary, and the dictionary would not be designed only for quick translation to a high number of languages in tight space, but for vocabulary, definitions, synonyms, antonyms, syntactic analysis, semantics management, and translation. In fact, we do that in other sections of the application. That is not the problem we are trying to solve here.
The current translation dictionary is setup somewhat like: ... <word en:title="Mr" f-en:title="Mrs" fr:title="M." f-fr:title="Mme" ... /> <word en:noun="chair" fr:noun="chaise" ... /> ...
all feminine variants can be returned with: /dic/word/@*[starts-with(name(.), 'f-')] all French feminine can be returned with /dic/word/@f-fr:* all French feminine adjectives can be returned with /dic/word/@f-fr:adjective all translated English words return form /dic/word/@en:* all English nouns, whatever gender, can be obtained with something like /dic/word/@*:nouns[contains(name(), 'en:')]
The reality is that this dictionary is used for translation and
the translated term is effectively returned by a key-based query that is more like
key('translator', $target, $dic)/@*[starts-with(name(), $lang)]
It must be good to know what is right from what is wrong,
especially with an absolute perspective.
I have to admit that I have always had some disbelief about absolute beliefs,
but I will keep an open mind, at least just in case.
Regards, Andre
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
ac wrote:
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.Subsequent calls to document()/doc() function are returning previously loaded and parsed document tree so there is no speed/memory penalty attached to it. Your transformation will use as much memory as is needed for languages used during this transformation.
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 have never taken part in a project where everything was known at the design time. Maybe be this is rare exception and you will be very lucky.
With pleasure. For example given your source: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?
<word en:instance="Mr" en-f:instance="Mrs" fr:instance="M." fr-f:instance="Mme" ... />
it would be very unnatural to write queries against such model. Imagine you need to retrieve for example:
- -- all English words - -- all female variant of word
In your example you are using namespaces to encode information which would be more natural to express as attribute/element values or their respective nesting.
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.Honestly, thread is too long to digest what you are referring too now. I'm just saying that way you are using namespaces for storing localization data is wrong. I'm not saying anything about other use of namespaces in your solution.
Jirka
- -- - ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@xxxxxxxx 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/
iEYEARECAAYFAk2tqbgACgkQzwmSw7n0dR72cwCeJAXsTMm9xiKhxOYXDWvEX/3/ TJcAoJN/DVjcZdEhM+mHIuViYqodFtXb =54ju -----END PGP SIGNATURE-----
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Was: [xsl] mode and moved to Na, Jirka Kosek | Thread | Re: Was: [xsl] mode and moved to Na, Jirka Kosek |
Re: Was: [xsl] mode and moved to Na, Jirka Kosek | Date | Re: Was: [xsl] mode and moved to Na, Jirka Kosek |
Month |