Yves, inline..
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
On Tue, Nov 6, 2012 at 12:01 PM, Yves Savourel
<ysavourel@enlaso.com> wrote:
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.
It is optional, as you do not need to support it, see my previous definition of support as read, understand, process, write as per its PRs
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.
This situation is not at all absurd. Module aware tools can remove module elements AS PER its PRs. Module unaware tools MUST NOT do it because they do not understand (do not need to understand) the module's PRs, AND as per our definitions of module and extension, they also CANNOT POSSIBLY have a VALID reason to modify modules, because if they had it they would have to support it, i.e. understand its PRs.
> 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.
This is surprising to me, as you first wanted to protect unconditionally both modules and extensions.
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.
I do not think they are. The modules are TC vetted (they are not ANYTHING that can come through a random custom extension) and module roundtrip cannot be guaranteed without unconditional protection from tools that do not support/understand it. This invalidates the idea of the module and prevents further development of the standard by adding modules. Who would care for adding modules if the roundtrip was not guaranteed.
Modules are optional only as long as you do not cover their functionality. If you do, they are as non-negotiable as the core is.
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
The difference is not artificial and does not need to be created, just honored. As I said before, special rules have always precedence over general rules, and describing non-core handling without making the distinction in a specific situation is not a counter-point here. If a module or extension has to be removed because the carrier core element is gone, so be it (I think this is a general principle and common sense for all core manipulations not just resegmenting). If there is a way to preserve (in case the successor carrier element can be identified), the module MUST be preserved and the extension SHOULD as per the general rule, if the special rule does not say otherwise.
(that would actually require more work)?
This will only create more work if you care to delete extensions, i.e. have valid reasons to delete them. Suppose a lean core only implementer who implements a behavior that always preserves modules and extensions (as long as they do not need to be removed as per a specific core PR). He will have honored both the MUST preserve for modules and SHOULD preserve for extension. He will only bother with identifying and deleting extensions if they actually cause trouble..
So more work is needed IFF the implementer wants to identify and delete an extension
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.
agreed
Those are all incentives for tool vendors to migrate their extensions to modules.
The effect of these incentives is thwarted if the modules are not protected from tools that do not understand them. or if they have the same level of protection as extensions.
Regards,
-yves