Hi,
From a Sling perspective having initial content without explicit namespace 
declaration is totally fine.
Therefore I wouldn’t call it ill-formed Sling initial content files.

But the converted DocView file is ill-formed (violating the spec) but still 
imported fine.

Having said this, FileVault serialisation does not support emitting those 
ill-formed DocView files, therefore the only middle ground would require really 
nasty workarounds like:

- Generate artificial namespace URIs for undeclared prefixes in cp2fm
- Let FileVault generate serialisations based on those artificial namespace URIs
- Remove all XML namespace declaration previously generated for the artificial 
namespace URIs again in cp2fm.

Another option would probably be to pass parameters to cp2fm for declaring 
additional namespaces.
Then downstream consumers could declare additional ones like “cq” and those 
would have known URLs then which would be taken into account for FileVault 
serialisation.

Konrad

> On 8. May 2023, at 18:07, Robert Munteanu <[email protected]> wrote:
> 
> Hi,
> 
> After cutting the cpconverter 1.3.2 release I noticed a change in
> behaviour with respect to ill-formed Sling initial content files. [1],
> [2]
> 
> Previously (in version 1.3.0), an initial file that used custom
> namespaces but did not declare them using bundle headers
> 
> e.g.
> 
> <node>
>    <primaryNodeType>nt:unstructured</primaryNodeType>
>        <node>
>            <name>my:subnode</name>
>            <primaryNodeType>nt:unstructured</primaryNodeType>
>        </node>        
>    </node>
> </node>
> 
> would generate an ill-formed DocView xml (aka FileVault format).
> However, that DocView xml would then be successfully processed when
> installing the bundle.
> 
> With version 1.3.2 this kind of file is rejected since we have moved to
> using FileVault for generating the DocView xml.
> 
> The FileVault refactoring is good and allows us to drop custom code and
> old dependencies. At the same time, since I spotted this problem when
> updating AEM tooling [3], I am concerned that there are projects out
> there using the ill-formed initial content format that will be broken.
> 
> As Konrad suggested, I'd like to hear what others think and maybe
> gather some new options to proceed. Currently we have:
> 
> 1. Keep the new behaviour
> 2. Revert to the old behaviour
> 
> I am not sure if there is a middle ground, Konrad says that the
> FileVault serialisation code cannot work with missing/invalid namespace
> mappings.
> 
> Thoughts?
> 
> Thanks,
> Robert
> 
> 
> [1]: https://issues.apache.org/jira/browse/SLING-11865
> [2]:
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/168
> [3]: https://github.com/adobe/aemanalyser-maven-plugin/pull/205

Reply via email to