Hi David, all,
> - A user agent that does not support a given module element or
> attribute MUST preserve it, except when a core processing requirement
> specifies otherwise.
It makes no sense to me that an optional module MUST be preserved. It's not optional anymore.
Furthermore, if core-only tools cannot remove a module, I assume the tools aware of the module can. So we would have the absurd situation where a tool that doesn't support module ABC must preserve it, but the tool XYZ that supports that module can remove it.
> Module data are not essential in the same way as core, but unlike
> extensions they are the essential and only possible way how to cover
> their specific functionality.
That doesn't make them special. I want tools to be able to get rid of any non-core constructs if they see a need for it.
The reason you listed for tools to get rid of the elements of a custom namespace are just as valid for the elements of a module.
As the PRs I've posted earlier illustrate, you can treat all non-core elements exactly the same when doing for example re-segmentation. Why create an artificial difference (that would actually require more work)?
The distinction between modules and custom namespaces exists:
- modules always have a schema.
- modules are documented and backed by the TC.
- modules could exist in places extensions could not.
Those are all incentives for tool vendors to migrate their extensions to modules.
Regards,
-yves
