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

Subject: Re: Was: [xsl] mode and moved to Namespaces
From: ac <ac@xxxxxxxxxxxxx>
Date: Mon, 18 Apr 2011 11:25:28 -0400
Hi Michel,

A very valid option, especially if the application is handling a language at a time. Why create and load a big dictionary if a small and simpler one does the trick? You are quite right.

OTOH, it seems more debatable, if the application is processing streamed content that could be set in any language at any time.

An application could load all relevant dictionaries, but it would need to select the dictionary, as well as the word, on every call, with more consumed space and more elaborate access.

Still, the option is valid and needs to be weighted out with the others.

I still get the impression that having, loading, and managing one dictionary per logical namespace is somewhat working around a natural fit, and a question keeps ringing in my mind: why? why avoid namespaces at efficiency costs, when they naturally fit the problem? are namespaces a "bad" thing?

Thank you for your valid suggestion.

Regards,
ac



Off topic, but wouldn't it be nicer to put the dictionary in a file by
language? And include/retrieve the proper one?

Michel

On Mon, Apr 18, 2011 at 3:34 PM, ac<ac@xxxxxxxxxxxxx> wrote:
Hi Michael,

Valid point.

Assuming 2 gender, 10 languages, and 10K words, version 2 requires 20
namespaces and 210K nodes, while version 1 requires no namespace and
810Knodes, in addition to common overhead.  Keys apply in both cases,
although with a theoretical 25% size factor advantage for version 2.  Also,
every dictionary check will require that version 1 passes two parameters
instead of one, as well as matches two attributes, instead of retrieving the
properly named one, although keys can contribute to reduce this last
retrieval factor difference.

As for maintenance, adding an additional language involves adding a new
namespace definition for version 2 and substantially more editing and data
entry for version 1.  Adding a new word is also somewhat simpler in version
2. But we are now getting into verbosity-related issues, which may not be
important factors, except for their associated typo increase factor.

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.

Weren't namespaces designed to be used?  If so, why avoid them at all costs,
especially in cases of natural conceptual namespaces?

Regards,
ac



Am 18.04.2011 um 07:16 schrieb ac:

  Yes I can create a dictionary like
<dic>
<word>
<instance xml:lang="en" gender="m">Mr</instance>
<instance xml:lang="en" gender="f">Mrs</instance>
<instance xml:lang="fr" gender="m">M.</instance>
<instance xml:lang="fr" gender="f">Mme</instance>
        ...
</word>
</dic>

but, given the proper namespace declarations, I could also have it as
<dic>
<word en:instance="Mr" en-f:instance="Mrs" fr:instance="M."
fr-f:instance="Mme" ... />
    ...
</dic>
IMO this is a good example why the perceived verbosity of some XML is a
good thing. Regarding flexibility and future maintenance the first version
has clear advantages: It requires almost no effort to add more languages, or
more genders (if needed) or other attributes to the dictionary if needed,
while the second version needs rules how to create new namespace names (and
an expanded name for each) and requires updates to the validation schema for
each change.

I would rank maintainability if XML sources far higher than the number of
nodes. Regarding performance of XSLT processors I dont think there is a
difference if the correct keys are defined.

- Michael

--
_______________________________________________________________
Michael M|ller-Hillebrand: Dokumentation Technology
Adobe Certified Expert, FrameMaker
Consulting and Training, FrameScript, XML/XSL, Unicode
Blog [de]: http://cap-studio.de/

Current Thread