Cocoon
  1. Cocoon
  2. COCOON-1529

I18nTranformer should consume and stop propagating start/endPrefixMapping of its namespace

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1.8, 2.1.9, 2.2
    • Fix Version/s: 2.1.12
    • Component/s: - Components: Sitemap
    • Labels:
      None
    • Environment:
      Operating System: other
      Platform: Other

      Description

      This is a strage bug.
      on http://localhost:8888/samples/i18n/simple.xml around line 183:
        <annotation xmlns:i18n="http://apache.org/cocoon/i18n/2.1">

      This produces wrong xml output (extra xmlns:i18n attribute).

      now if you commented out the annotation element then the xmlns:i18n attribute
      goes to the next element:
       <content xmlns:i18n="http://apache.org/cocoon/i18n/2.1">

      It looks like it goes to the parent element always.

      I wish that I could have more information about how to resolve this.

        Activity

        Juan Jose Pablos created issue -
        Hide
        Jörg Heinicke added a comment -
        Can you go a bit more in details as I do not really understand.
        Show
        Jörg Heinicke added a comment - Can you go a bit more in details as I do not really understand.
        Jeff Turner made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 35348 12324838
        Pier Fumagalli made changes -
        Workflow jira [ 12341273 ] Cocoon Workflow [ 12341462 ]
        Vadim Gritsenko made changes -
        Component/s - Components: Avalon [ 12310445 ]
        Description This is a strage bug.
        on http://localhost:8888/samples/i18n/simple.xml around line 183:
          <annotation xmlns:i18n="http://apache.org/cocoon/i18n/2.1">

        This produces wrong xml output (extra xmlns:i18n attribute).

        now if you commented out the annotation element then the xmlns:i18n attribute
        goes to the next element:
         <content xmlns:i18n="http://apache.org/cocoon/i18n/2.1">

        It looks like it goes to the parent element always.

        I wish that I could have more information about how to resolve this.
        This is a strage bug.
        on http://localhost:8888/samples/i18n/simple.xml around line 183:
          <annotation xmlns:i18n="http://apache.org/cocoon/i18n/2.1">

        This produces wrong xml output (extra xmlns:i18n attribute).

        now if you commented out the annotation element then the xmlns:i18n attribute
        goes to the next element:
         <content xmlns:i18n="http://apache.org/cocoon/i18n/2.1">

        It looks like it goes to the parent element always.

        I wish that I could have more information about how to resolve this.
        Component/s - Components: Sitemap [ 12310447 ]
        Bugzilla Id 35348
        Hide
        Jörg Heinicke added a comment -
        Is it really a bug or just a superfluous namespace declaration?
        Show
        Jörg Heinicke added a comment - Is it really a bug or just a superfluous namespace declaration?
        Jörg Heinicke made changes -
        Status Open [ 1 ] On Hold [ 10000 ]
        Hide
        Juan Jose Pablos added a comment -
        It is a superfluous namespace declaration.
        Show
        Juan Jose Pablos added a comment - It is a superfluous namespace declaration.
        Hide
        Jörg Heinicke added a comment -
        So I hope your are ok with closing the bug. Issues with superfluous namespace declarations have to be fixed in the pipeline (if they need to be fixed at all), e.g. by adding an additional transformer or the infamous stylesheet: http://wiki.apache.org/cocoon/RemoveNamespaces.
        Show
        Jörg Heinicke added a comment - So I hope your are ok with closing the bug. Issues with superfluous namespace declarations have to be fixed in the pipeline (if they need to be fixed at all), e.g. by adding an additional transformer or the infamous stylesheet: http://wiki.apache.org/cocoon/RemoveNamespaces .
        Jörg Heinicke made changes -
        Status On Hold [ 10000 ] Closed [ 6 ]
        Resolution Invalid [ 6 ]
        Hide
        Jörg Heinicke added a comment -
        Carsten mentioned on the list that it is not that difficult if the transformer extends AbstractSAXTransformer: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113285830305619&w=4. Unfortunately I18nTransformer does not extend AbstractSAXTransformer, but even this refactoring should not be that difficult.
        Show
        Jörg Heinicke added a comment - Carsten mentioned on the list that it is not that difficult if the transformer extends AbstractSAXTransformer: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113285830305619&w=4 . Unfortunately I18nTransformer does not extend AbstractSAXTransformer, but even this refactoring should not be that difficult.
        Jörg Heinicke made changes -
        Status Closed [ 6 ] Reopened [ 4 ]
        Resolution Invalid [ 6 ]
        Jörg Heinicke made changes -
        Bugzilla Id 35348
        Summary I18ntranformation output xmlns:i18n in the first element I18nTranformer should consume and stop propagating start/endPrefixMapping of its namespace
        Affects Version/s 2.1.9-dev (current SVN) [ 12310650 ]
        Priority Major [ 3 ] Minor [ 4 ]
        Affects Version/s 2.1.8 [ 12310601 ]
        Jean-Baptiste Quenot made changes -
        Assignee Cocoon Developers Team [ cocoon ] Jean-Baptiste Quenot [ jbq ]
        Jean-Baptiste Quenot made changes -
        Assignee Jean-Baptiste Quenot [ jbq ]
        Hide
        Johannes Textor added a comment -
        IMHO, there is no reason that i18n transformer should propagate its namespace, since it consumes all elements in that namespace. The remaining xmlns attribute is annoying if one serializes to XHTML, since the result is not valid. It is of course possible to "fix" this problem by adding an additional transformation step to each pipeline to drop the namespaces, but that costs performance and messes up the sitemap code.

        I looked into Joerg's AbstractSAXTransformer but I think that I18nTransformer should not be refactored to inherit from it; AbstractSAXTransformer is based on the assumption that the transformer will only use elements within a given namespace, but I18nTransformer also translates *attributes* on elements which might be in a different namespace (via i18n:attr). OTOH, AbstractSAXTransformer does a lot of things such as keeping track of all namespaces and calling extra "hook" methods which are not needed by I18nTransformer and would just slow it down.

        Attached is a simple patch (against I18nTransformer.java as of 20 Feb. 2008) which achieves the desired effect by simply dropping all prefix mappings which are in one of the i18n namespaces. WDYT?
        Show
        Johannes Textor added a comment - IMHO, there is no reason that i18n transformer should propagate its namespace, since it consumes all elements in that namespace. The remaining xmlns attribute is annoying if one serializes to XHTML, since the result is not valid. It is of course possible to "fix" this problem by adding an additional transformation step to each pipeline to drop the namespaces, but that costs performance and messes up the sitemap code. I looked into Joerg's AbstractSAXTransformer but I think that I18nTransformer should not be refactored to inherit from it; AbstractSAXTransformer is based on the assumption that the transformer will only use elements within a given namespace, but I18nTransformer also translates *attributes* on elements which might be in a different namespace (via i18n:attr). OTOH, AbstractSAXTransformer does a lot of things such as keeping track of all namespaces and calling extra "hook" methods which are not needed by I18nTransformer and would just slow it down. Attached is a simple patch (against I18nTransformer.java as of 20 Feb. 2008) which achieves the desired effect by simply dropping all prefix mappings which are in one of the i18n namespaces. WDYT?
        Johannes Textor made changes -
        Attachment I18nTransformer.java.diff [ 12376036 ]
        Hide
        solprovider added a comment -
        The i18n transformer requires users to add the transform to each pipeline. In my experience, the i18n transformer is always called just before a Serializer. Resolving i18n tags should happen in two situations:
        1) Translation during serialization before leaving an XMAP. Unresolved i18n elements must remain for later processing.
        2) Translation before presenting the information. Unresolved i18n elements should translate to the default and be removed. The i18n namespace should be removed.

        The first case can be integrated into the XMLSerializer.
        The second case can be integrated into final Serializers such as the HTMLSerializer.
        Since the XMLSerializer can be used in both situations, an "i18n-finalize" parameter can decide if the defaults should be used and the i18n namespace be removed. An "i18n-ignore" parameter could be used for when performance matters and the i18n functionality is not useful, but new users would benefit from the reduced code of the default functionality.

        Each Serializer can have "i18n-catalog" parameters. These catalog parameter could be made unnecessary by having a default catalog name related to the sitemap, e.g. sitemap.xmap defaults to using sitemap_i18n_xx.xml and sitemap_i18n.xml from the same directory.
         
        Some people may argue against mixing Transformer functionality into Serializers. Serialization is a transformation possibly resulting in a non-XML data format. I18n functionality is ubiquitous and a major benefit of Cocoon. Integrating i18n into Serializers removes the need for building a comprehensive catalog for use in the final step before the final transformation/serialization; each XMAP handles its unique i18n translations and leaves unknown translations for later processing.

        This suggestion does not expect the removal of the i18nTransformer. Allowing the i18nTransformer to be called without serialization may prove useful and is necessary for backwards-compatibility.

        As a non-integrated Transformer, the i18nTransformer should distinguish between interim transforms that translate only elements from the current catalogs and final transforms that resolve every i18n element/attribute and remove the i18n namespace.
        Show
        solprovider added a comment - The i18n transformer requires users to add the transform to each pipeline. In my experience, the i18n transformer is always called just before a Serializer. Resolving i18n tags should happen in two situations: 1) Translation during serialization before leaving an XMAP. Unresolved i18n elements must remain for later processing. 2) Translation before presenting the information. Unresolved i18n elements should translate to the default and be removed. The i18n namespace should be removed. The first case can be integrated into the XMLSerializer. The second case can be integrated into final Serializers such as the HTMLSerializer. Since the XMLSerializer can be used in both situations, an "i18n-finalize" parameter can decide if the defaults should be used and the i18n namespace be removed. An "i18n-ignore" parameter could be used for when performance matters and the i18n functionality is not useful, but new users would benefit from the reduced code of the default functionality. Each Serializer can have "i18n-catalog" parameters. These catalog parameter could be made unnecessary by having a default catalog name related to the sitemap, e.g. sitemap.xmap defaults to using sitemap_i18n_xx.xml and sitemap_i18n.xml from the same directory.   Some people may argue against mixing Transformer functionality into Serializers. Serialization is a transformation possibly resulting in a non-XML data format. I18n functionality is ubiquitous and a major benefit of Cocoon. Integrating i18n into Serializers removes the need for building a comprehensive catalog for use in the final step before the final transformation/serialization; each XMAP handles its unique i18n translations and leaves unknown translations for later processing. This suggestion does not expect the removal of the i18nTransformer. Allowing the i18nTransformer to be called without serialization may prove useful and is necessary for backwards-compatibility. As a non-integrated Transformer, the i18nTransformer should distinguish between interim transforms that translate only elements from the current catalogs and final transforms that resolve every i18n element/attribute and remove the i18n namespace.
        Cédric Damioli made changes -
        Fix Version/s 2.1.12-dev (Current SVN) [ 12312903 ]
        Hide
        Cédric Damioli added a comment -
        Committed in revision 1413784
        Thanks !
        Show
        Cédric Damioli added a comment - Committed in revision 1413784 Thanks !
        Cédric Damioli made changes -
        Status Reopened [ 4 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Hide
        Juan Jose Pablos added a comment -
        Hey, that was quick! :-)

        Created 14/Jun/2005
        Fixed 26/nov/2012



        --
        El hombre bien comido y bien bebido, quiere reposo y no ruido.

        Show
        Juan Jose Pablos added a comment - Hey, that was quick! :-) Created 14/Jun/2005 Fixed 26/nov/2012 -- El hombre bien comido y bien bebido, quiere reposo y no ruido.
        Hide
        Cédric Damioli added a comment -
        Never say never ... ;-)
        Show
        Cédric Damioli added a comment - Never say never ... ;-)

          People

          • Assignee:
            Unassigned
            Reporter:
            Juan Jose Pablos
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development