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

[ac <ac@xxxxxxxxxxxxx>]

Hi Jirka,

I appreciate your time, consideration, suggestions, and arguments.

You are right, there is a lookup cost, and this is not the way I prefer 
to use namespaces.  OTOH, the space saving and associated overhead 
saving can justify the lookup cost for something that can get large and 
needs to stay in busy memory, at least for a while.

It would be much nicer if namespaces could be further supported, 
including support for hierarchical namespaces, as well as namespace 
optimization.  Namespaces are, apart from comments, one of the three 
basic XML constructs. Three isn't much, which is fine, but each should 
be maximized to help better satisfy application requirements.

I do not doubt that you are open-minded and I certainly appreciate your 
constructive comments.  In fact I agree with them.  I do admit that 
"simply wrong" did not allow me to understand and contribute 
technically.  But it is looking much better now.

I also realize that matching on the names is risky and would be better 
addressed through the URIs.  The added cost is not high enough to 
justify the risk, and the space saving is probably still worth the 
effort, depending on the number of languages that need to be supported, 
the size of the vocabulary, and the memory constraints.

Still, as everything is a trade off, I would still maintain, given all 
constraints, that this is another valid use case for namespaces, when it 
applies.  I would also recommend that we consider how namespaces can 
better fulfill more useful roles in XML, including how they can be 
expanded, and more efficiently supported.

There is a real conceptual need for namespaces and it may be that we are 
just starting to better realize it.

Regards,
ac



> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ac wrote:
>
> > The current translation dictionary is setup somewhat like:
> > ...
> > <word en:title="Mr" f-en:title="Mrs" fr:title="M." f-fr:title="Mme" ... />
> > <word en:noun="chair" fr:noun="chaise" ... />
> > ...
> >
> > all feminine variants can be returned with:
> > /dic/word/@*[starts-with(name(.), 'f-')]
> Such lookups will tend to be quite slow because matching on name of
> element/attribute can't be done using dictionary -- high efficient XSLT
> implementations doesn't store element/attributes names for each node,
> but they store just number pointing to dictionary with the real
> qualified name. This saves memory and makes matching on name very fast.
> But if name is not directly present in XPath such fast matching can't be
> done.
>
> > all French feminine can be returned with
> > /dic/word/@f-fr:*
> > all French feminine adjectives can be returned with
> > /dic/word/@f-fr:adjective
> > all translated English words return form
> > /dic/word/@en:*
> The trouble with such approach is that you can't change language during
> the runtime. You have to pregenerate all queries before running
> transformation or use dynamic XPath evaluation (which is not part of
> XSLT standard yet).
>
> > all English nouns, whatever gender, can be obtained with something like
> > /dic/word/@*:nouns[contains(name(), 'en:')]
> If you are using namespaces then this code is not correct. You should
> match on namespace name not actual prefix used. So query should be more
> like:
>
> /dic/word/@*:nouns[namespace-uri() = 'whatever URI was assigned to en']
>
> > It must be good to know what is right from what is wrong,
> > especially with an absolute perspective.
> > I have to admit that I have always had some disbelief about absolute
> > beliefs,
> > but I will keep an open mind, at least just in case.
> I consider myself very open-minded. Your usage for namespaces in this
> particular case surely works for you, but it's misuse of namespaces.
> They were not designed for this and their usage for this several
> engineering flaws.
>
> - --
> - ------------------------------------------------------------------
>    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/
>
> iEYEARECAAYFAk2t+6cACgkQzwmSw7n0dR4F/ACfRIwtkthd9SXVzk4fV+iKoHoe
> XbkAnR6T4sWLdIzdyi/+J9gjIr/V8jEd
> =1Loa
> -----END PGP SIGNATURE-----