> Dear colleagues,
> I managed to write the second part, which caused a lot of brain
> damage.
> Here goes.
> Regards,
> Makoto
> --------------------------------------------------------------------------- --------------
> 7. Versioning
> Section 1.2.4 of the EPUB content spec shows a versioning strategy.
> The IDPF anticipates revising the EPUB 3 specifications if and
> when such incompatible changes occur, updating the normative
> constraints defined herein as necessary and incrementing the
> minor version number of EPUB 3 (e.g., publishing an
> EPUB 3.0.n).
> This strategy implies that each minor version of EPUB3 has slightly
> different versions of properties derived from CSS WDs and that reading
> systems have to behave differently depending on the minor version.
> Reading systems could reply on the version attribute of the package
> document or property prefixes (e.g., epub301-, epub302-).
> Note: I contacted Simon Fraser (a member of the CSS WG) of Apple.
> He wrote:
>> We also have a strong preference to avoid -epub3 and -epub4 prefixes,
>> since we do not want the additional burden of supporting multiple
>> obsolete
>> behaviors in perpetuity. We'd prefer a single -epub prefix.
> In my interpretation, Apple is against the EPUB versioning strategy.
> 8. Possible options
> There are two major options, unprefixed or prefixed properties in EPUB
> CSS Profile, and two variations.
> 8.1 Unprefixed properties
> EPUB CSS Profile has unprefixed properties (rather than prefixed ones)
> borrowed from CSS WDs. EPUB reading systems support these unprefixed
> properties. EPUB stylesheets contain unprefixed properties but no
> prefixed properties.
> 1) Pros
> - If the final recommendations do not change the borrowed properties,
> this approach ensures longevity and leads to no forks.
> 2) Cons
> - If the final recommendations or interim drafts change
> the borrowed properties, this approach provides a fork and
> fails to ensure longevity (unless we rewrite EPUB publications
> by conversion).
> - The upcoming corpus of EPUB publications will cause lock-in: it
> will become difficult for the CSS WG to change the properties even
> when there are good reasons.
> 8.2 Prefixed properties
> EPUB CSS Profile has prefixed properties (rather than unprefixed ones)
> derived from CSS WDs. EPUB reading systems support these prefixed
> properties. EPUB stylesheets contain prefixed properties but no
> unprefixed properties.
> 1) Pros
> - This approach ensures longevity if future EPUB reading systems
> continue to
> support the prefixed properties in EPUB3.
> - This approach does not cause lock-in to the current design.
> - If the final recommendations or interim drafts do not change the
> borrowed properties, the EPUB fork merely provide syntactical
> aliases thus providing little overhead.
> 2) Cons
> - If future EPUB reading systems do not support the prefixed
> properties,
> we will lose longevity.
> - The EPUB fork caused by this approach will lead to significant
> burdens especially when the semantics of the EPUB fork become
> different from those of the final CSS recommendations or interim
> drafts.
> 8.3 Unprefixed properties after prefixed ones
> This option is a variation of 8.2 Prefixed properties. Differences
> are as follows:
>> EPUB CSS Profile has prefixed properties (rather than unprefixed
>> ones)
>> derived from CSS WDs.
> This is slightly changed. Unprefixed properties are also allowed.
>> EPUB reading systems support these prefixed properties.
> No changes. However, when the referenced CSS specs becomes W3C
> recommendations, EPUB reading systems are expected to support prefix
> properties.
>> EPUB stylesheets contain prefixed properties but no
>> unprefixed properties.
> This is slightly changed. Each prefixed property in a stylesheet is
> followed by an unprefixed property. For example, epub-writing-mode is
> followed by writing-mode. If both prefixed and unprefixed properties
> are supported by a reading system, the unprefixed one (e.g.,
> writing-mode) wins.
> 1) Pros
> - If the final recommendations do not change the borrowed properties,
> this approach ensures longevity. An implementation can easily
> migrate
> from prefixed properties to unprefixed ones.
> - If the final recommendations do not change the borrowed properties,
> the EPUB fork is merely a collection of aliases and is thus not
> serious.
> 2) Cons
> - If the final recommendations or interim drafts change
> the borrowed properties, this approach provides two forks:
> a prefixed fork and an unprefixed fork.
> - If the final recommendations or interim drafts change
> the borrowed properties, this approach fails to ensure
> longevity (unless we rewrite EPUB publications by conversion).
> If reading systems start to support unprefixed properties, the
> existing
> corpus of EPUB publications will not work.
> - Although unprefixed properties are simply ignored by upcoming
> reading systems, they arguably cause lock-in. If reading
> systems start to support unprefixed properties, the existing
> corpus of EPUB publications will not work.
> Simon wrote:
>> I've checked with other people here at Apple, and we agree on the
>> following,
>> from an implementor's perspective:
>> * EPUBs should use the -epub prefix for CSS3 properties that are
>> not in CR.
>> * For future compatibility, EPUBs should include an unprefixed
>> property
>> declaration after the prefixed one, in most cases[1].
>> As an implementor, we have the following considerations:
>> * We share the same code between EPUB viewers and the web browser
>> * We have a strong desire to avoid content-specific behaviors (i.e.
>> we will
>> not add behavior that only triggers if an EPUB is being displayed).
>> * Thus, we cannot expose unprefixed properties to EPUB only
>> We also have a strong preference to avoid -epub3 and -epub4 prefixes,
>> since we do not want the additional burden of supporting multiple
>> obsolete
>> behaviors in perpetuity. We'd prefer a single -epub prefix.
>> I think that the -epub prefix is also of benefit to authors, since
>> it indicates that:
>> 1. the behavior is not stable, and subject to change in future
>> versions of a given UA
>> 2. the behavior may be different in different UAs.
> 8.4 Unprefixed properties *before* prefixed ones
> This option is only slightly different from the previous one. In this
> option, each unprefixed property in a stylesheet is followed by a
> prefixed property. For example, writing-mode is followed by
> epub-writing-mode. If both prefixed and unprefixed properties are
> supported by a reading system, the prefixed one (e.g.,
> epub-writing-mode) wins.
> 1) Pros
> - If the final recommendations do not change the borrowed properties,
> this approach ensures longevity. An implementation can easily
> migrate
> from prefixed properties to unprefixed ones.
> - If the final recommendations do not change the borrowed properties,
> the EPUB fork is merely a collection of aliases and is thus not
> serious.
> - Even when the final recommendations change the borrowed properties,
> this approach ensures longevity as long as future EPUB reading
> systems continue to
> support the prefixed properties in EPUB3.
> - If reading systems continue to support the prefixed properties in
> EPUB3,
> the upcoming corpus of EPUB publications will not cause lock-in,
> since unprefixed properties continue to be ignored.
> 2) Cons
> - If the final recommendations or interim drafts change
> the borrowed properties, this approach provides two forks:
> a prefixed fork and an unprefixed fork.
> - If the final recommendations or interim drafts change
> the borrowed properties, reading systems cannot stop
> the support of prefixed properties without hampering
> longevity (unless we rewrite EPUB publications by conversion).
> - Although unprefixed properties are simply ignored by upcoming
> reading systems, they arguably cause lock-in. If reading systems
> start to support unprefixed properties and stop the support of
> prefixed properties, the existing corpus of EPUB publications
> will not work any more.
> --
> Praying for the victims of the Japan Tohoku earthquake
> Makoto
