| View previous topic :: View next topic |
| Author |
Message |
IDPF IDPF Member

Joined: 04 Jan 2006 Posts: 32 Location: Canada
|
Posted: Wed Jul 11, 2007 2:33 pm Post subject: Final IP Notice Period Called; OPS/OPF 2.0 Elevated |
|
|
Dear IDPF Members,
This is a formal notice regarding Intellectual Property Claims as it relates to the Proposed Open Publication Structure (OPS) 2.0 and Open Packaging Format (OPF) 2.0 specifications.
On July 2, 2007, the IDPF Board of Directors voted to elevate OPS/OPF 2.0 to a Proposed Document with a recommendation to vote "FOR" elevating its status to "Recommended Specification", an official IDPF specification. On July 10, 2007, the OEBPS Working Group voted to call for a Final Notice Period as per the IDPF Intellectual Property Rights ("IPR") Policy. The Final Notice Period will begin today, July 11, 2007 and last for 45 days ending on August 27, 2007. The IDPF IPR Policy can be found at:
http://www.idpf.org/doc_library/corporate%20documents/ippolicy/IDPF_IP_Policy.htm
Pursuant to the IDPF IPR Policy, members are required to disclose any Essential Claims and provide a Licensing Statement based on the OPS/OPF 2.0 Proposed Documents. To fulfill your obligations, please fill out the attached IP Disclosure Form and return to IDPF Executive Director, Nick Bogaty, by the end of the Final Notice Period. Please note, if do not have have any Essential Claims on the OPS/OCF 2.0 Proposed Documents, you do not need to reply to this notice.
The OPS/OCF 2.0 Proposed Documents and the IP Disclosure Form can be found at:
http://www.idpf.org/2007/ops/index.htm
A redlined version of the specifications reflecting changes to the document as a result of the public and IDPF member review periods and a summary of all comments received and actions taken by the Working Group are also available on the above website for review.
Following the Final Notice Period, the IDPF Board of Directors will present the Proposed Document with the results, if any, of the Final Notice Period to the IDPF Membership for a vote. This remote (via email) vote will require a Super Majority to approve the Proposed Document.
Best,
Nick
--
Nick Bogaty
Executive Director
International Digital Publishing Forum (IDPF) |
|
| Back to top |
|
 |
b.wolterding
Joined: 05 Feb 2007 Posts: 15 Location: Europe
|
Posted: Tue Jul 31, 2007 6:00 am Post subject: Issue #24 (Non-spine item fallback requirements) |
|
|
Regarding issue 24 from the public review period, I'm not quite sure what is intended. Reading the response posted, it seems that fallbacks need to be provided for non-core content documents only if they are referenced from the spine.
On the other hand, section 2.3.1.1 of the draft specification 0.987 still seems to say that fallbacks are required for all non-core items in the manifest.
Could someone clarify? |
|
| Back to top |
|
 |
Garth Conboy IDPF Member

Joined: 08 Nov 2006 Posts: 10 Location: La Jolla, California
|
Posted: Wed Aug 01, 2007 5:07 pm Post subject: |
|
|
The stated resolution to issue #24 should represent the intent of the fix on this topic. It looks like section 2.4 was updated correctly, but 2.3.1.1 was not tuned in a matching fashion.
As was pointed out, for example, non-core image types may be referenced by <img> elements and their fallbacks may be inherent within the tag, thus not requiring a manifest-based fallback. Similarly for <object> elements, they have internal/nested fallback processing (similar to the handling of inline XML islands).
So, technically the first sentence of 2.3.1.1 is correct "An item that specifies a resource that is not an OPS Core Media Type (e.g. a non-core image type, a text file, a PDF file) must have a fallback specified." There being an implied "fallback (of some sort) specified" at the end of the sentence -- a fallback of some type must be provided (perhaps within an <img> or <object> element).
It's the second sentence of 2.3.1.1 that is misleading "In this case, its fallback must be identified with a fallback attribute pointing to another item." It should say something along the lines of "If a fallback is not otherwise specificed by other supported means, its fallback must be identified with a fallback attribute pointing to another item." |
|
| Back to top |
|
 |
|