As currently proposed, option 2 does not allow extensions. Valid values
of the manifest:preferred-view-mode attribute are the three listed in the
proposal, and no more.
If we wanted to allow additional values, and encourage uniqueness, we
could allow IRI values as well, like "
http://www.google.com/schemas/odf/view-mode1".
This is similar to package naming conventions in Java, where the use of
packages like com.ibm.Foo piggybacks on the domain name registry
uniqueness.
Of course, nothing can force ODF users to do this correctly, so we can
never enforce global uniqueness. But we can encourage it.
Doing this change would look like this:
But do we want to go down that path? This solution, although I've seen it
used in other standards, is not used in ODF anywhere else, to my
knowledge, although the issues of extensibility and namespace collisions
are universal. I dislike introducing a new design pattern, and have it be
used in only one place. "Creeping elegance" is the term that comes to
mind.
Other ways of handling this might be:
1) Apply this technique throughout ODF, wherever we currently have a fixed
enumeration and we wish to allow additional custom choices.
2) Don't add the IRI support to the schema, but in some introductory
material, specify that any identifiers used in extensions "should" or
"shall" be based on IRI's in order to encourage global uniqueness.
Regards,
-Rob
"Warren Turkal"