| View previous topic :: View next topic |
| Author |
Message |
IDPF
IDPF Member
Joined: 04 Jan 2006
Posts: 32
Location: Canada
|
 Posted: Mon Apr 16, 2007 1:11 pm Post subject: OPS 2.0 Elevated to IDPF Member & Public Review |
 |
|
The Open Publication Structure (OPS) 2.0 has been elevated for IDPF Member and Public Review. The review period will begin today and extend for 30 days ending on Wednesday, May 16th, 2007. The IDPF strongly encourages feedback from potential users, developers and others, whether IDPF members or not, for the sake of improving the interoperability and quality of IDPF work. Feedback on the draft specification should be made on this forum topic.
Document Summary
On March 29th, 2007 the OEBPS Working Group agreed to submit the OPS 2.0 Working Draft Specification into the official IDPF output process as a Submitted Document as per the IDPF Policies & Procedures 4.6.2 (Approving an Official Document). On Thursday, April 12th, 2007, the IDPF Board of Directors voted to elevate the document to Draft Status for IDPF Member and Public Review. The Draft Review Period will begin on Monday, April 16th, 2007 and last for 30 days, ending on Wednesday, May 16th, 2007. The specifications are available at:
OPS 2.0: http://www.idpf.org/2007/ops/OPS_2.0_0.984_draft.html
OPF 2.0: http://www.idpf.org/2007/opf/OPF_2.0_0.984_draft.html
Feedback on the draft specifications should be made by posting a reply to this forum topic.
Specification Summary
The OPS 2.0 and OPF 2.0 specifications are successors to OEBPS 1.2 which was released as an official IDPF specification in August 2002. The OPS specification describes a standard for representing the content of electronic publications. The OPF specification defines the mechanism by which the various components of an OPS publication are tied together and provides additional structure and semantics to the electronic publication. OPS/OPF will increase the viability and adoption of the previous OEBPS standard as both a cross-reading system interchange and production format as well as a final publication delivery format.
Both OPF and OPS are aligned with the OEBPS Container Format (OCF) specification which defines the standard mechanism by which all components of an electronic publication may be packaged together into a single archive for transmission, delivery and archival purposes. The OCF specification was released as an official IDPF specification on October 27th, 2006.
Ouput Procedure & How to Make Comments on OPS 2.0
The Working Group will maintain a record of all IDPF Member and Public Comments during this 30 Day Comment Period. At the end of the Comment Period, the Working Group will record their actions on each comment and submit the revised Draft Document, Comments and Actions to the IDPF Board of Directors for a Final Board Review. Following the Final Board Review, if elevated by a vote from the IDPF Board of Directors, the document will undergo an IP Notice Period of 45 days. The IP Notice Period will be followed by an IDPF Membership Vote which will require a Super Majority to approve the Proposed Document as a Recommended Document (Official Specification) in the IDPF.
Feedback on the draft specifications should be made by posting replies to this forum topic.
I would like to thank all of the contributors to these documents especially Garth Conboy and Brady Duga of eBook Technologies, Inc., Peter Sorotokin of Adobe Systems, Inc., George Kerscher of the DAISY Consortium, Jon Noring of DigitalPulp Publishing and Ben Trafford for their hard work and time.
Best,
Nick Bogaty
--
Nick Bogaty
Executive Director
International Digital Publishing Forum (IDPF) |
|
| Back to top |
|
 |
Daniel.Weck
Joined: 16 Apr 2007
Posts: 4
|
| Posted: Mon Apr 16, 2007 10:19 pm Post subject: Re: OPS 2.0 Elevated to IDPF Member & Public Review |
|
|
Topic: OPS vs OPF mismatch.
At:
http://www.idpf.org/2007/opf/OPF_2.0_0.984_draft.html#Section2.4.2
- in the text:
"The NCX as defined in the ANSI/NISO Z39.86-2005 Standard Section 8 is ideal for OPS applications"
and:
"audio is not used in the OPS application of the NCX"
ACTION
=> shouldn't "OPS" be replaced by "OPF" ?
This would then make consistent the use "OPS Publication" and "OPF Application", throughout the document.
_________________
Daisy-For-All Project (DFA)
Software Developer
Last edited by Daniel.Weck on Mon Apr 16, 2007 11:31 pm; edited 4 times in total |
|
| Back to top |
|
|
Daniel.Weck
Joined: 16 Apr 2007
Posts: 4
|
| Posted: Mon Apr 16, 2007 11:29 pm Post subject: |
|
|
Topic: references to the W3C SMIL standard.
Neither OPS nor OPF make actual use of the SMIL specification (syntax and semantics).
However, each document needs to refer to it, for the sake of outlining the differences with ANSI/NISO Z39.86-2005, essentially regarding NCX's use of SMIL.
ACTION
In the OPF spec., I think a link reference to the SMIL specification is missing:
http://www.idpf.org/2007/opf/OPF_2.0_0.984_draft.html#Section2.4.2
=> for consistency, I would suggest using the same SMIL version as the one in ANSI/NISO Z39.86-2005:
http://www.w3.org/TR/2005/REC-SMIL2-20050107/
The "Relationship to Other Specifications" section in both OPS and OPF is labeled with:
"This specification combines subsets and applications of other specifications. Together, these facilitate the construction, organization, presentation, and unambiguous interchange of electronic documents"
See:
http://www.idpf.org/2007/ops/OPS_2.0_0.984_draft.html#Section1.3
and
http://www.idpf.org/2007/opf/OPF_2.0_0.984_draft.html#Section1.3
ACTION
=> In the OPS spec., I think this should be removed:
"14. Synchronized Multimedia Integration Language (SMIL 2.1) (http://www.w3.org/TR/2005/REC-SMIL2-20051213/)"
...because OPS does not actually use anything from SMIL (the only feature I see is "switch", but it meets different requirements and is clearly differentiated).
ACTION
Still in the OPS spec., I would suggest adding new link reference to SMIL here:
http://www.idpf.org/2007/ops/OPS_2.0_0.984_draft.html#Section2.4.2.1
=> again for consistency, I would recommend using the same SMIL version as the one in ANSI/NISO Z39.86-2005:
http://www.w3.org/TR/2005/REC-SMIL2-20050107/
ACTION
In the OPS spec., at:
http://www.idpf.org/2007/ops/OPS_2.0_0.984_draft.html#Section2.6.3.1
...in the text:
"The switch element is a concept used in both SVG 1.1 and SMIL 2.1;"
=> I would not use SMIL "2.1" as this seems to emphasize on the .1 update of the 2.x major specification version. Instead, I would link to the latest SMIL 2 version, which is available here:
http://www.w3.org/TR/SMIL2/
In fact, the switch was introduced in SMIL 1.0 ! However it would be silly to link so far in the past  :
http://www.w3.org/TR/1998/REC-smil-19980615/#switch
_________________
Daisy-For-All Project (DFA)
Software Developer |
|
| Back to top |
|
|
Daniel.Weck
Joined: 16 Apr 2007
Posts: 4
|
|
| Back to top |
|
|
Daniel.Weck
Joined: 16 Apr 2007
Posts: 4
|
|
| Back to top |
|
|
b.wolterding
Joined: 05 Feb 2007
Posts: 15
Location: Europe
|
| Posted: Fri Apr 27, 2007 12:40 pm Post subject: Package document in multiple files? |
|
|
Per section 1.2, the OPF package document can be split across multiple files via the XML entity mechanism.
In my opinion, this is very inconvenient for implementations, in particular if combined with OCF containers. I therefore propose to drop it from the specification.
Consider an application that is interested only in the publication metadata within an .epub file. This could be a routine that catalogizes numerous epub files on the file system, or a file browser that displays file-specific metadata "on the fly".)
If the OPF package document is contained in only one file, the metadata can be read by extracting this specific file from the ZIP container and then parsing the XML. Actually, the file can easily be parsed from the ZIP stream without ever involving a temporary "extracted" file on the file system. This is rather lightweight and fast.
However, if the OPF package document is split across multiple files, there are some severe complications. The application must now either
* investigate the OPF root file before(!) invoking the XML parser, in order to find out whether and which additional files will be needed for parsing, and extract these from the ZIP file to the file system; or
* rather deeply modify the XML parser in order to enable it to load entity files directly from the ZIP stream (this is not standard functionality); or
* extract the entire ZIP file, including all content documents, to the file system before parsing the package document.
While the first two options introduce "only" unneccessary complications, the third one will rather be unfeasible due to performance reasons, in particular for large packages.
In my opinion, these complications by far outweigh the additional "flexibility" (if any) that is gained by allowing external entities in the OPF package file. |
|
| Back to top |
|
|
b.wolterding
Joined: 05 Feb 2007
Posts: 15
Location: Europe
|
| Posted: Fri Apr 27, 2007 12:44 pm Post subject: Required attribute "title" for "reference&quo |
|
|
| Section 2.6 ("Guide") does not list the "title" attribute of the "reference" tag as required. (At least I did not find this in the text.) However, the RelaxNG schema treats "title" as a required attribute. This should be clarified. |
|
| Back to top |
|
|
b.wolterding
Joined: 05 Feb 2007
Posts: 15
Location: Europe
|
| Posted: Fri Apr 27, 2007 12:51 pm Post subject: Files with .opf extension |
|
|
Section 1.4.1.1 states that, if the OPF package document is split into multiple files, only the root file must have the ".opf" extension.
Is it allowable for other files in the manifest (other than the parts of the package document) to end in ".opf"? (Section 2 does not state the contrary.) If so, how is the OPF package document identified? |
|
| Back to top |
|
|
b.wolterding
Joined: 05 Feb 2007
Posts: 15
Location: Europe
|
| Posted: Fri Apr 27, 2007 1:05 pm Post subject: List of constraints incomplete |
|
|
Section 1.4.1.2 reads:
| Quote: |
A collection of files is a conforming OPS Publication if and only if:
(12 items listed)
|
I am not sure about this "if and only if". In fact, the list of 12 conditions seems to be incomplete. The specification lists a number of other constraints that an OPF package must satisfy; just to name a few:
* fallback chains must terminate,
* a fallback must be given for any file that is not of an OPS core media type,
* href attributes in the manifest must not contain fragment identifiers,
* href attributes in guide references must refer to a file listed in the manifest,
and many more. So, taking section 1.4.1.2 literally, a package with a cyclic fallback chain would be a "conforming OPS Publication", although not being in line with the OPF specification. Is this intended?
In any case, it would be very useful to have a complete list of constraints that need to be satisfied for an OPF document (other than conforming to the RelaxNG schema).
Last edited by b.wolterding on Fri Apr 27, 2007 1:35 pm; edited 1 time in total |
|
| Back to top |
|
|
b.wolterding
Joined: 05 Feb 2007
Posts: 15
Location: Europe
|
| Posted: Fri Apr 27, 2007 1:18 pm Post subject: required "id" attribute in "dc:identifier& |
|
|
Is the "id" attribute of the "identifier" element in the Dublin Core metadata a required attribute?
Quoting Sec. 2.2.10:
| Quote: |
| At least one identifier must have an id specified, so it can be referenced from the package unique-identifier attribute described in Section 2.1. |
This would mean that "id" is not a generally required attribute, it needs to be specified only for one of the identifier elements.
The RelaxNG schema however reads:
| Code: |
<define name="DC.identifier-element" ns="http://purl.org/dc/elements/1.1/">
<element name="identifier">
<attribute name="id">
<data type="ID"/>
</attribute>
<ref name="OPF20.optional-xsi-type"/>
<ref name="OPF20.optional-scheme-attribute"/>
<ref name="DC.metadata-common-content"/>
</element>
</define> |
By this specification, the "id" attribute is required for all identifier elements.
Last edited by b.wolterding on Fri Apr 27, 2007 1:33 pm; edited 1 time in total |
|
| Back to top |
|
|
b.wolterding
Joined: 05 Feb 2007
Posts: 15
Location: Europe
|
| Posted: Fri Apr 27, 2007 1:32 pm Post subject: "Hidden features" in the RelaxNG schema |
|
|
There seem to be some aspects of the OPF format that are specified only in the RelaxNG schema, but are not mentioned appropriately in the specification text.
As an example, the RelaxNG schema allows the "xml:lang" attribute for many (but not all) elements. This is hardly mentioned in the textual specification; the only reference I found was a small note in Sec. 2.2.1, saying
| Quote: |
| Determination of the most appropriate titles is not defined by this specification, but may include the available fonts, an examination of xml:lang attributes, or other heuristics. |
and a similar one in Sec. 2.2.2.
I think it would be more appropriate to describe this "feature" more clearly in the textual specification, maybe stating "the xml:lang attribute is allowed for the following elements:", and explaining its semantics.
Something similar applies to the "id" attribute, which is allowed for all elements. This is mentioned, again, only in a side note in Sec. 2.2, where it would not be expected. The semantics of this field is also explained only for special cases.
Maybe it would be enough to introduce a section on "common attributes", and stating that the general id attribute is "reserved for future use" (if this is the case). |
|
| Back to top |
|
|
Jon Noring
Joined: 05 May 2007
Posts: 2
|
| Posted: Sat May 05, 2007 11:29 am Post subject: Comments on OPF Section 2.4 about the spine |
|
|
Section 2.4 of the OPF specification is ambiguous with regards to whether or not all the content documents which are "reachable" via hypertext links must include an <itemref> in the <spine>.
For example, we have the following two statements which appear to conflict with each other:
| Quote: |
| Reading Systems must display in some fashion all auxiliary content items if such items can be reached through hyperlinks, even if the auxiliary content items are not included in the linear navigation order. |
and
| Quote: |
| All content reachable in the publication must be referenced with itemref elements. |
(Of course, there may not be a conflict between the two statements depending upon how the phrase "linear navigation order" is interpreted, which is not clearly defined, unfortunately.)
Because of the critical importance of the <spine> in the specification, section 2.4 needs to be streamlined to reflect the true intent of the Working Group. I recommend that we include two numbered lists, one for the Publication authoring requirements, and one for Reading System requirements. Sort of a check list. (As it stands now, everything is blended together rather than cleanly separated.)
The need to clarify the role, purpose and importance of auxiliary content
In addition, the role and purpose of auxiliary content is left completely undiscussed (it's not even in the definitions section.) This is a serious rollback of the OEBPS innovation informally termed "out-of-spine" content -- effectively a burial before it is even dead.
I'd like to see a paragraph or two (or better yet a separate non-normative section) mentioning what it is and how it may enhance the e-book reading experience. It would also strongly urge Reading System developers to implement it (that is, to specially recognize "linear="no"') in conformity with our general vision, or at least to realize it may become critical in the future so Reading System developers may today architecture their systems in such a way to more easily adapt to non-linear publications in the future.
Thus, I would include in that section something like the following statement (not necessarily this exact wording, but something that clearly communicates the essence):
| Quote: |
| A future version of the OPS specification may support highly non-linear publication types, such as web site structures. To prepare for that future, OPS Reading System developers *should* design their systems so that they recognize "linear="no"' content documents as not being a part of the linear reading order, and present such content in a way that communicates to the user that such content is not part of the main linear reading order of the publication. |
If we don't do this, we have effectively buried one of the great innovations in OEBPS and harm the future of OPS when it will need to handle more non-linear content types we see in several publication industries, including web site structures, newspapers, topic-based publications, and hypertext literature, to name a few.
With the current lame and vague wording, Reading System developers will very likely assume all publications are, and will always be, purely linear, and architecture their systems accordingly. This is likely to create a serious impediment to future expansion of OPS to handle non-linear publications we see in several publication industries (and industries IDPF is trying to woo into the fold!) by simple inertia of the existing installed base. Reading System developers will, to avoid major rewrites of their code, stymie efforts to support non-linear publications and their presentation, thereby creating a permanent state of affairs where OPS is stuck in the backwater of "linearity," erecting a permanent brick wall between narrative and other more non-linear types of publications which, in reality, are much more common than narrative type of works.
We don't want to do that. |
|
| Back to top |
|
|
Jon Noring
Joined: 05 May 2007
Posts: 2
|
| Posted: Sat May 05, 2007 1:40 pm Post subject: Discussion points to clarify OPS/NCX requirements |
|
|
When I built the "epub" My Ántonia, and included an NCX, I carefully read the OPF section on NCX as well as the relevant section in the DTBook spec. I believe the resulting NCX for My Ántonia meets all minimum requirements spelled out in OPF 2.0.
Here's the link to the "epub" and inside the NCX: http://www.idpf.org/2007/ops/samples/myantonia.epub
But I believe we should better understand these requirements, and determine if we are comfortable with them before finalizing the OPS/OPF 2.0 specs. They appear to lead to a couple uncertainties, and might add a couple Reading System requirements we may not be aware of yet and might be burdensome for OPS purposes. If needed, some clarification in the OPF spec may be needed depending upon our intent.
So, let's start with the top. The OPF spec says the following about the NCX used in an OPS 2.0 Publication (referred herein as "OPS/NCX"):
| Quote: |
| The NCX file must be a valid XML document conforming to 'ncx-2005-1.dtd' and comply with the additional normative requirements defined in http://www.niso.org/standards/resources/Z39-86-2005.html. The 'version' and 'xmlns' attributes on the <ncx> element must be explicitly specified in the document instance, using values drawn from the above-named DTD. |
This leads to the following requirements for OPS/NCX documents (may not be complete for our purposes, but covers what I consider the items of importance for all OPS/NCX used for XHTML-based OPS Publications):
1) The NCX must be a "valid XML document" in the XML sense -- one cannot interpret it any other way given the present wording. (Even if one assumes a different interpretation, the other requirement that OPS/NCX follow DTBook requirements settles this issue -- an OPS/NCX MUST be valid in the XML 1.x sense, meaning it includes a DOCTYPE referencing the NCX DTD and other ramifications regarding prefixed namespaces.)
2) Because of validity requirements, the following items which otherwise do not appear that important for OPS use MUST appear in an OPS/NCX document (I've limited this discussion to <navMap> and <navList> sections -- ignoring <pageList> -- since they are most likely to be used in OPS/NCX for non-DTBook Publications):
a) The 'version' and 'xmlns' attributes on the root <ncx> must be explicitly specified and must be set to the values FIXED in the NCX DTD. (Not much of a burden, really, and a good idea.)
b) The <head>...</head> section must appear immediately following the root <ncx>.
c) The <head> section must include at least one <meta name=..." content="..."/> element whether or not needed for OPS purposes. (By a different DTBook requirement, four particular <meta/> are required -- see later.)
d) <docTitle> following <head> is required. (But <docAuthor> is not.)
e) Each <navLabel> and <navTarget> must include the attributes 'id' and 'playOrder'. 'playOrder' is important for accessibility, and will be discussed later regarding Reading System conformance.
3) Here's the list of DTBook NCX requirements beyond validation which OPS/NCX must conform:
a) The <head> section MUST include the following four <meta/> items: "dtb:uid", "dtb:depth","dtb:totalPageCount",and "dtb:maxPageNumber". The last two are especially useless for OPS/NCX use, but must appear anyway. A fifth is recommended by DTBook NCX: "dtb:generator".
b) there are numbering requirements for 'playOrder'.
Following are what I see to be the requirements for Reading Systems in processing/using OPS/NCX (for now I'm only considering <navMap> and <navList> sections, ignoring <pageList>):
1) An NCX may also include one or more <navList> sections. I interpret our spec to indicate that an OPS 2.0 Reading System must support/use, in some fashion, all the optional <navList> in the OPS/NCX, and not only use the <navMap> which is considered the primary table of contents. In the OPS/NCX for "My Antonia", I include a <navList> for all the illustrations in the book, a "list of illustrations".
2) It is more unclear whether an OPS 2.0 Reading System must implement for visual users the 'playOrder' attribute values. It is a sort of overall "tour" of the Publication. We should clarify this.
To summarize discussion points
O.k., that's my findings. To summarize, we should discuss the following:
1) For OPS/NCX used for non-DTBook Publications, should we relax the <meta/> requirements, and only require one or two of them to appear? (Currently four are required by DTBook, two of which seem pretty useless -- at least one <meta/> must appear to assure validity to the DTD.)
2) Must OPS 2.0 Reading Systems also process/use any <navList> that can optionally appear in an OPS/NCX? I say yes. If we decide not to require this, we should at least say Reading Systems should, and in a future spec we may require it.
3) Must OPS 2.0 Reading Systems use the required 'playOrder' attribute values, or make it optional? (I'd say yes, and interpret 'playOrder' as some sort of overall "tour" of the publication -- if we don't agree to this, we should recommend it and state it may be made a requirement in the future.) |
|
| Back to top |
|
|
linus.ericson
Joined: 15 May 2007
Posts: 5
|
| Posted: Tue May 15, 2007 5:15 pm Post subject: a couple of typos |
|
|
In the OPF draft, section 1.4.3, second item of the list:
"in" should be replaced by "is".
In the OPF draft, Appendix A:
The name of the attribute on the meta element should be "scheme" and not "schema", right?
In the OPS draft, section 1.3.5, the third from last paragraph says:
"External style sheets linked via the XHTML link element or by the processing instruction xml-stylesheet..."
A "can be" or similar seems to be missing between the third and fourth word.
In the OPS draft, section 3.3:
The oeb-column-number property in the table should be underlined. |
|
| Back to top |
|
|
linus.ericson
Joined: 15 May 2007
Posts: 5
|
| Posted: Tue May 15, 2007 5:20 pm Post subject: missing dtbook references |
|
|
In the OPS draft, section 2.5.2:
Shouldn't the following be added as an item to the list:
"References from DTBook img elements"
In the OPS draft, section 3.0:
The second and fourth paragraph after the css examples only describe XHTML content documents and not DTBook content documents. |
|
| Back to top |
|
|
|
FAQ 
Search 
Memberlist 
Usergroups
Register
Profile 
Log in to check your private messages 
Log in 
