[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: Mon, 18 Apr 2011 16:54:29 +0200
Re: Was:  mode and moved to Namespaces
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

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.