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

[Michel Hendriksen <michel.hendriksen@xxxxxxxxx>]

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/