Altova Mailing List Archives


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

From: ac <ac@---------.--->
To: xsl-list@-----.------------.---
Date: 4/19/2011 1:53:00 AM
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@k...      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@l...>
> --~--
>
>

--~------------------------------------------------------------------
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@l...>
--~--

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.