Re: [Bug 20445] New: - i18n transformer does not recognize 2.0 namespace

[Sylvain Wallez <sy...@anyware-tech.com>]

Bruno Dumon wrote:

>On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote:
>  
>
>>I guess, legacy support won't be readded, so this is a WONTFIX?
>>    
>>
>
>yes, I agree. A bit of a problem though is that upon encountering the
>old namespace, the I18nTransformer nicely logs a warning, however the
>log level is error by default. Maybe we should lower it to warn instead?
>
>(there are other components also logging deprecation warnings not
>visible by default)
>

We should make a difference between deprecation (still works, but likely 
to disappear in the future), and detection of abandoned features.

So IMO, if the old i18n namespace is detected but not supported, then 
the message should be an error, since the feature is no longer provided.

But this leads to another question : why did we loose backwards 
compatibility ? I'm a bit ignorant about the evolutions that led to 
change the namespace, but why haven't we kept the old transformer beside 
a new one handling the new namespace ?

This would have allowed a smooth migration path by not breaking existing 
applications. Of course, the old transformer should log a deprecation 
warning encouraging users to migrate to the new one.

So what about renaming the new transformer to I18nTransformer2 and 
re-adding the old I18nTransformer ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [Bug 20445] New: - i18n transformer does not recognize 2.0 namespace

[Konstantin Piroumian <kp...@apache.org>]

From: "Sylvain Wallez" <sy...@anyware-tech.com>
> Bruno Dumon wrote:
> >On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote:
> >
> >
> >>I guess, legacy support won't be readded, so this is a WONTFIX?
> >>
> >>
> >
> >yes, I agree. A bit of a problem though is that upon encountering the
> >old namespace, the I18nTransformer nicely logs a warning, however the
> >log level is error by default. Maybe we should lower it to warn instead?
> >
> >(there are other components also logging deprecation warnings not
> >visible by default)
> >
>
> We should make a difference between deprecation (still works, but likely
> to disappear in the future), and detection of abandoned features.
>
> So IMO, if the old i18n namespace is detected but not supported, then
> the message should be an error, since the feature is no longer provided.

Agree.

>
> But this leads to another question : why did we loose backwards
> compatibility ? I'm a bit ignorant about the evolutions that led to
> change the namespace, but why haven't we kept the old transformer beside
> a new one handling the new namespace ?

I should take a look at the differences more carefully. I can't remember any
serious changes in syntax, except new extensions. The namespace was changed
to indicate the different syntax.

At the time of introducing the new namespace I asked the list if there are
any objections and didn't get anything in reply, so I droped the old one to
reduce the maintenance.

>
> This would have allowed a smooth migration path by not breaking existing
> applications. Of course, the old transformer should log a deprecation
> warning encouraging users to migrate to the new one.
>
> So what about renaming the new transformer to I18nTransformer2 and
> re-adding the old I18nTransformer ?

Personally, I am -0 for having two different transformers doing almost the
same thing just because I don't have any time now to devote to it. Though,
it's quite easy to get the i18n transformer from C 2.0 and modify it to be
compatible with C 2.1, then rename the new one to I18nTransformer2 (but what
about the reversion history?).

Maybe it'd be easier to provide a stylesheet that will transform 2.0 syntax
to 2.1? And maybe a target in build to perform this in batch mode.

--
  Konstantin

>
> Sylvain
>
> -- 
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
>