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

Re: Was: mode and moved to Namespaces

Subject: Re: Was: mode and moved to Namespaces
From: Michel Hendriksen <michel.hendriksen@xxxxxxxxx>
Date: Tue, 19 Apr 2011 09:16:13 +0200
Re: Was:  mode and moved to Namespaces
Hi,

I understand namespaces to differentiate between elements with the
same name that mean something different. Like "fork" could be a
utensil used to process food, but could also be a branch in a tree or
road. These are different things.

You seem to use namespaces to, a.o, translate different names for the
same thing and maybe even in the content. The locator example is maybe
more a format thing then, but still means a location.

So to me it looks like you are using namespaces in a more creative
way, and if it all works then that would be ok.

And to come back to the original point, there are cases where people
use more then a few namespaces so optimizing namespace search/lookup
might be a good thing to consider.

Michel

On Tue, Apr 19, 2011 at 3:52 AM, ac <ac@xxxxxxxxxxxxx> wrote:
> 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@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/
>>
>> iEYEARECAAYFAk2so8YACgkQzwmSw7n0dR6/aACfU2uWCc8holTZPQkbLBFuwVYr
>> cO8AmgJSyK7Vr8O0SxKWQpbFqDRFNfb2
>> =/1uR
>> -----END PGP SIGNATURE-----

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.