100 likes | 226 Views
CSS Relations. MURATA Makoto 村田 真 IDPF EPUB WG/EGLS Coordinator ISO/IEC JTC1/SC34/AHG4(EPUB) Co- convenor. Outline. CSS specs and properties required for reasonable EGLS support Design Space Normative references or non-normative references? Dated references or undated references?
E N D
CSS Relations MURATA Makoto 村田 真 IDPF EPUB WG/EGLS Coordinator ISO/IEC JTC1/SC34/AHG4(EPUB) Co-convenor
Outline • CSS specs and properties required for reasonable EGLS support • Design Space • Normative references or non-normative references? • Dated references or undated references? • Warning about instability? • Should we attach the prefix idpfor epub3 to properties? • Should we copy syntactical definitions and/or semantics definitions from references? • Implementation-dependent or implementation-defined?
Normative references or non-normative references? • Normative references • We are dependent: we incorporate normative things from non-normative references as part of EPUB3. • We do not have to provide our own normative descriptions. • Conformance to EPUB3 requires conformance to normative references. • Non-normative references • We are standalone: we do not incorporate anything from non-normative references but we simply mention them. • We are required to provide our own normative descriptions. • Conformance to EPUB3 does not require conformance to non-normative references.
Dated references or undated references? • Dated • We ignore all future versions but stick to the referenced version. • The referenced version might become obsolete soon. • Undated • We use the latest version. • Risky since incompatible changes may happen.
Warning about instability? • Warning may allow implementers to do breaking changes. • Warning may discourage the adoption of EPUB3.
Should we attach the prefix idpfor epub3 to properties? • Without the prefix • Politically incorrect? • Future conflicts between EPUB3 and CSS3 may happen. • With the prefix • Looks ad-hoc • Future conflicts are avoided. • When CSS becomes mature, we might want to remove the prefix. • We have to define the syntax and semantics.
Should we copy syntactical definitions from references? • If we copy, then: • Even if we do not have normative references, we can define syntax of CSS properties. • We can define our own subset by copying –and-modifying. • We will have some IPR risks (but Microsoft, Mozilla, and webkit already do copy) [Fair use] • If we don’t copy, then: • We got to have normative references unless we are willing to make everything undefined. • We will have no IPR risks.
Should we copy semantics definitions from references? • If we copy, then • We can define semantics of borrowed properties without having normative references. • We will have lots of IPR risks • If we don’t copy, then • We might want to define the semantics by ourselves, which is risky. • Or, we might simply make the semantics implementation-dependent or implementation-defined. (But we can provide non-normative references)
Implementation-dependent or implementation-defined? • “Implementation-dependent” means implementations can do anything. • “Implementation-defined” means that implementations are required to provide documentation for the adopted definitions.