People will be choosing to author HTML5 or OPS 3.0 content. HTML5 is a widely 
known and somewhat sexy term, OPS is not, nor it its spelled out term "Open 
Publication Structure" particularly meaningful or accurate given that it 
defines the content not the structure. Because we use the XHTML MIME type there 
is no compatibility issue relative to this name. So we could consider changing 
OPS to some other term as part of EPUB3, to improve our marketing and 
discourage unnecessary use of the HTML5 content type. "DTBook2", "HTML5 Plus", 
or "Reliable XHTML5"? (not serious proposals).

Issue per George K.

Currently the OCF spec mandates, in the section on META-INF/encryption.xml, 
that encryption.xml should be used to provide font decoding information if 
obfuscation of fonts is desired, and includes a reference to the font-mangling 
spec.

I wonder whether this is necessary, or whether the font-mangling spec itself 
should be responsible for defining all the aspects of its implementation.  The 
OCF spec might be read as mandating use of font-mangling as the only way to 
obfuscate fonts, but that's ambiguous here.  If we want to tighten that up, 
then that's another direction we could go, but I think then that would require 
some elaboration on font-mangling.  Perhaps even merge the specs?

we already decided to specify CSS 2.1 normatively, in its entirety.

notes #6 and #13 will survive the the removal of the explicit CSS table.  These 
are the ones (Garth believes) that refer to OPS-specific properties that are 
not in CSS 2.1.

A minor nit. NCX becoming part of OPF was clearly an evolutionary process: is 
the "toc" attribute a relic of that history or something fundamental? It seems 
that now that it's required that there be a single NCX document in the 
manifest, it's not totally clear why Reading Systems would require a TOC 
attribute in the spine in order to locate it. Can Reading Systems realistically 
defer processing the manifest XML? Do Reading Systems even utilize this 
attribute? If we are going to have a special attribute in the spine for NCX, 
why not for other things?

We have a goal to minimize burden on content authors so if it's not adding 
value I'd prefer to see it deprecated, as it just seems a bit ugly.

spec:

"...The spine element must include the toc attribute, whose value is the the id 
attribute value of the required NCX document declared in manifest "

Reading Systems may want to know whether an EPUB3 publication includes MathML 
markup without having to parse and scan all of the content. Consider a 
technique for declaring the presence of MathML inside a content item (or whole 
document?).

It was previously decided that EPUB3 should change "Reading Systems SHOULD 
support NCX" to "Reading Systems MUST support NCX". Implications of this change 
relative to Guide are not clear to me.

In particular, I cannot find words to express why one might want to author 
Guide as well as NCX in EPUB3 since both seem to express the notion of a 
declarative Table of Contents. If there is no logical reason, other than 
backwards compatibility of Reading Systems with old content and of EPUB3 
content that can work with old Reading Systems, then
we should consider removing from content conformance (leaving support for Guide 
as a Reading System conformance) or at least deprecating (clarifying that we 
view it as a vestigial construct there due to history). If we don't 
remove/deprecate we need to find a way to express why one might want to create 
a Guide that is not backwards-looking.

We believe EPUB content exists that includes "Guide". It is not clear to me 
whether such content always includes an "NCX" nor how they relate to each other.

Spec details:

In OPF 2.0.1 Guide is defined as "A set of references to fundamental structural 
features of the publication, such as table of contents, foreword, bibliography, 
etc." NCX is defined as "A declarative global navigation definition". authors 
MUST include NCX and MAY include Guide, Reading Systems SHOULD support NCX 
(silent about, so presumably MAY support Guide).

Metadata subgroup divided on how specific this vocabulary should be. Currently 
the recommendation includes values of primary, short, long, sub, series, 
collection, edition, slang. Main question: inconsistent publisher use of 
"series" vs. "collection," lack of clarity as to how they nest. Some feel we 
should not attempt to specify such values at all, and simply rely on integers 
to distinguish title-type 1, title-type 2, etc.; others think these specific 
recommended types are useful, but the spec prose needs to explain the 
distinctions clearly.

For full description see:

http://www.daisy.org/epub/issues/use-relax-ng-text-pattern-schema-title-identifi
er-and-others

When we're drafting OPF language this time around, it seems likely we should 
disallow empty content in the four required "dc:" metadata elements (e.g. 
dc:title, dc:identifier); we already have required content verbiage for 
dc:language.

During drafting, we need to make sure to incorporate are agreed 2.0.1 Errata 
from:

http://www.daisy.org/epub/project/issues/epubmaint?sid=2

ISO and IEC use modal verbs (such as "shall" and "should") differently 
from IETF.

Since the IDPF board is favor of standardization at ISO and/or IEC, 
I think that we should follow ISO and IEC rather than IETF.

See Annex H (normative) Verbal forms for the expression of provisions

http://www.iec.ch/tiss/iec/Directives-Part2-Ed5.pdf

OCF defines an "Abstract Container" with two concrete instantiations, a "ZIP 
Container" and a "Filesystem Container". However, the "Abstract" container is 
not so abstract from a Web architecture perspective, as it is defined as "a 
file system model ... [that] MUST have a single common root directory for all 
of the contents ... special files REQUIRED by OCF MUST be included within the 
META-INF directory that is a direct child of the root directory... All 
(non-remote) electronic assets for embedded publications MUST be located within 
the directory tree headed by the container’s root directory."

HTML5 OTOH normatively defines itself as processing a "stream of bytes" and 
loading "resources". It does speak of files but really only in explanatory 
information. Other Web Standards define their processing model in terms of 
resources, as does the overall REST Architecture of the Web ( 
http://www.w3.org/TR/webarch/ ).

In our specs the closest to this comes at OPF, as OPF's core Package Document 
abstraction really is defined in terms of URI-addressed resources with MIME 
types, nicely Webby and RESTy. But it presently uses the term "file" 
normatively and frequently, the term "resource" rarely.

This may all seem just nomenclature baloney but the practical question 
underlying is is - when is it legitimate for resources in a (non-zipped) EPUB 
being accessed over a network to be dynamically generated e.g. by a web server? 
And what does that term "non-remote" in OCF spec really mean, if a "Filesystem 
Container" EPUB is being served in parts over a network?

It could be argued that either a package.opf or container.xml pointing at same 
is a sufficient entry point to process an "Exploded EPUB" over the network that 
is not necessarily going to ever be zipped up and again may not preexist as 
individual files: the cover image may be generated on the fly with the photo of 
the user in it. But if this is legit (and with Books in Browser multiplying due 
to be more prevalent) then we should perhaps be thinking about specifying stuff 
in a somewhat more general manner, at least for OPF and perhaps even for OCF. 
E.g., path segments in http URLs don't necessarily correspond to directories, 
and "remote" vs. "non-remote" may boil down to absolute vs. relative URI 
addressing.

ePub 2.1 (Open Packaging Format (OPF) 2.0.1 v1.0.1) uses MARC relator code 
list[1] for specifying the role of creators, which disregards completely the 
different possible roles in comics creation.

  [1]: http://www.loc.gov/marc/relators/

While ePub 3 intends to support ONIX (and hence I guess its [ONIX Books Code 
Lists][2], which does at least contemplate part of the idiosyncrasy of comic 
authorship, it is still insuficient. Code A40 indicates, for example, "Inked or 
colored by", two roles very clearly differentiated in the comic ecosystem.

  [2]: http://www.editeur.org/14/Code-Lists/

Some roles in comic authorship that a digital publication should allow to 
clearly and unequivocally declare are:

*   written by
*   pencil by
*   ink by
*   art by
*   color by
*   lettering by 

but there are more.

This is a very quick attempt to summarize a long on-list discussion ("Re: 
Authoring pain & requirements").  While providing a good signature that can be 
verified without understanding Zip or XML (container.xml), the "must be first, 
must be unadorned, must be uncompressed" restrictions make EPUB harder to 
create that may be needed.  Suggestion (some mutually exclusive):

-- Make "mimetype" optional
-- Allow trailing whitespace (e.g. "\r", "\n") on "application/epub+zip" in 
mimetype file content.
-- Allow "mimetype" to be anywhere and adorned and compressed

I (Garth) can't say I love this relaxation... but, the issue is logged for 
future discussion/decision.

Publishers in China and Hong Kong need to produce synchronized text/audio books 
with two parallel audio tracks,  each in a different language, of which only 
one will be chosen for playback.  The text for both audio tracks is the same -- 
for example Cantonese and Mandarin are written the same way but sound 
completely different.

The proposal is to introduce two SMIL files, each written according to the 
Text/Audio Sync proposal, and offer a switch at the OPF level.  The user 
indicates their language preference and the reading system loads the 
corresponding SMIL file.

To do: come up with OPF-level syntax for the switch described here.  It could 
be similar to the way RDFa is used for metadata to indicate alternate scripts.

Editor requests feedback.

OPS 2.0.1 and OPF 2.0.1. jointly describe fallback processing rules that 
preclude object element references from participating in the manifest-level 
fallback chain mechanism.

Reading Systems may use fallback chain for img elements (but not required do so 
do as imgs can have "alt" text as an "intrinsic fallback", which in the spec is 
deemed "sufficient").

iframe was not in OPS 2.0.1 but is in XHTML5 and thus presumed "in" with 
everything else for EPUB3.

Since there is no intrinsic fallback with iframe, there's an argument that 
Reading Systems should at least be allowed to, if not required to, process 
fallback chain for references as they may do with images and must do in general 
unless otherwise specified. If we are silent about iframe in the spec then this 
would appear to be the default result.

A perhaps unintended consequence would be that the out-of-line XML Islands 
(CSS-style XML) fallbacks would then be spec'd to work with this nested 
content, not just top level (spine) content as is implicitly the case today.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.
This relates to the metadata wg. The idea is that the EPUB version maybe used 
side-by-side with the print version and this aligns the association.

Several places in OPF 2.0.1, sec 2.3.1, it says "X should be considered a Core 
Media Type, thus fallback information must not be provided" (X = NCX, OpenType 
fonts, etc.)

But later on sec 2.4 says "...it is possible to have a fallback chain for a 
spine item that 'falls over' another OPS Core Media type. For example, a spine 
itemref could reference a PDF document, that falls back to a PNG image, that in 
turn falls back to a OPS XHTML Content Document."

This implies it is legitimate to have fallback information for items of Core 
Media Type, and there is nothing that says this is limited to items referenced 
from spine. Nothing elsewhere that I can see prohibits supplying 
fallback information for Core Media Types in general, unless the "thus" in sec 
2.3.1 be deemed to imply such a general prohibition.

My planned fix is to change each appearance of the "X should be considered a 
Core Media Type, thus fallback information must not be provided" construction 
to "Fallback information may not be provided for items of type X" (the "should 
be considered a Core Media Type" could be retained but seems redundant to state 
it, esp. without the "thus").

Putting it in tracker mainly to solicit feedback in case I got this wrong.

As they are only usable for spine (aka chapter) content it's hard for me to get 
too excited about this extremely limited "extensibility" mechanism, which 
creates quite a bit of spec complexity and some implementation burden.

We are adding code+data separation for object element, which will make the 
spine-level XML islands with CSS only even less attractive. 

Does anyone have content which uses these out-of-line XML Islands? How widely 
is it supported by Reading Systems? If it's not used now, and there's no use 
case for it that wouldn't be better off with code/data separation, then I would 
argue it could be deprecated or removed. Conversely, if we think extensibility 
in this way is important I could argue we should generalize code/data 
separation to work on XML spine items as well as "objects".

- track new proposal to require specific embedded font type(s) support for 
Reading System conformance (OpenType and/or WOFF?)
- reference a version of OpenType spec
- consider implications of browser WOFF support vs. W3C spec draft status
- consider implications of SVG Fonts support being implicitly specified in OPS 
2.0.1 based on "SVG 1.1 minus animations" (3 cases: direct use in SVG, 
CSS-styled SVG, CSS styles in HTML)
- font mangling spec - what do to about it

We have more leaf docs in EPUB3 - at a minimum we get Media Overlays, plus 
non-normative Overview and Changes docs. NCX may be a separate doc and the 
current draft organization has a separate "EPUB Publications 3.0" spec. This is 
still a bit fluid but one thing that might help resolve the inherent tension 
between separate leaf specs being good from a modularity and potential reuse 
perspective, but not necessarily easy to navigate, would be to decide not to 
create non-normative EPUBs for each individual spec, but to have a single 
non-normative EPUB3.epub document. Each individual spec could be a logical 
chapter (and concrete spine item). This kind of makes sense to me as while our 
current specs are each "books" in DocBook with multiple "chapters", these are 
really more like sections.

Basically if most people get EPUB3.epub as their single docset, with an 
umbrella TOC in NCX form and the Overview coming first as roadmap, it seems 
like it wouldn't matter as much how we sliced the salami of the other specs.

We could also in that case have acknowledgments and contributors live in one 
place not every leaf document. This information takes up quite a bit of space.

EPUB generation is low priority for now but deciding now what we want to do 
later may help us take final spec granularity decisions sooner.

OPS 2.0.1 references SVG 1.1 [1], whereas the HTML5 draft references SVG Tiny 
1.2 [2].

Should OPS3 for harmonization purposes also move to 1.2 Tiny? This solution 
would entail
* making validity towards 1.2 Tiny a 3.0 content conformance requirement
* making support for 1.1 a 3.0 reading system conformance requirement 
(backwards compat)

[1] http://www.idpf.org/doc_library/epub/OPS_2.0.1_draft.htm#Section2.5
[2] http://dev.w3.org/html5/spec/Overview.html#refsSVG

for package-level metadata

specs will have an EPUB3 Overview umbrella document that serves as an 
introduction as well as a starting point to and roadmap for the various 
individual specifications (of which we will now have even more, as NCX becomes 
our spec and we get Media Overlays).

http://www.w3.org/TR/owl2-overview/ is an example; 
http://www.w3.org/QA/WG/2005/08/spec-variability/#umbrella discusses the need 
for and role of such umbrellas.

Editor requests fodder for same - lower priority as it is entirely 
non-normative but I'd  like to have something in there sooner rather than later 
and I know many of you have introduced EPUB to people before.

People will be choosing to author HTML5 or OPS 3.0 content. HTML5 is a widely 
known and somewhat sexy term, OPS is not, nor it its spelled out term "Open 
Publication Structure" particularly meaningful or accurate given that it 
defines the content not the structure. Because we use the XHTML MIME type there 
is no compatibility issue relative to this name. So we could consider changing 
OPS to some other term as part of EPUB3, to improve our marketing and 
discourage unnecessary use of the HTML5 content type. "DTBook2", "HTML5 Plus", 
or "Reliable XHTML5"? (not serious proposals).

Issue per George K.

Currently, there are three areas identified where it is desirable to list 
alternatives:

 # [http://code.google.com/p/epub-revision/wiki/ImplementationProposalsMetadata#The_new_DCTERMS_elements_and_'ancillary_properties' metadata ancillary properties]
 # alternate audio overlays for different languages that share the same text
 # [http://fantasai.inkedblade.net/style/specs/altss-tags/ alternate style tags]

Need to investigate how to harmonize the syntax for these three similar 
features as much as possible.

we may wish to re-re-integrate some of that spec wording for OCF 3.0

SVG 1.2 Tiny (2008) gets a bit cute in normatively referencing CSS 2 
specification but with "no longer maintained", "implementors may wish to refer" 
etc. really pointing at 2.1:

*****
Except for any additional SVG-specific rules explicitly mentioned in this 
specification, the normative definition of properties that are shared with CSS 
and XSL is the definition of the property from the CSS 2 specification [CSS2]. 
Note: The CSS 2 specification is no longer maintained, and implementors may 
wish to refer instead to its future replacement, CSS 2.1 [CSS21], for more 
precise details. SVG 1.2 Tiny refers to CSS 2 due to the maturity of that 
specification on the W3C Recommendation track.
*****

2.1 was a Candidate Recommendation circa Dec 2008 (since superseded by 2 
subsequent CR versions, I believe) but I don't think SVG 1.2 Tiny would have 
been able to get to full Recommendation even if it was referencing a Proposed 
Recommendation (likely the most we could hope for in our timeframe). If CSS 2.1 
stays as CR or PR then perhaps we could follow the SVG 1.2 Tiny precedent if 
need be, perhaps even excluding explicitly by list any properties that are in 
CSS2 but not CSS2.1 + our CSS3 modules (if any). This is all semantics that 
might not help implementors or interoperability but might help path to 
ISO-level standardization and W3C relations (i.e. we would not be violating "It 
is inappropriate to cite this document as other than work in progress" which is 
on PRs as well as CRs).

Decided at the SFO F-to-F

Hi all,

I've been searching for "headers ad footers" issues, but didn't find any :-)
So my question is: "Are headers and footers included in the ePUB 3 specs?

Gert Lems 

OPS 2.0.1 sec 1.3.8 says somewhat vaguely "This specification includes support 
for the XML style sheet processing instruction". While OPS generally covers 
content documents (XHTML) it also touches on out-of-line XML Islands, but it 
seems clear that the spec doesn't preclude it being used for both (Earlier the 
spec says: "Style sheets can be associated with an OPS Content Document ...
by an external style sheet identified via the processing instruction 
xml-stylesheet"). This leads to several questions I'd love help with.

1. what is the Reading System conformance requirement for supporting this? I 
presume a "may", or a "must" but only for CSS content or ??. Do Reading Systems 
currently implement it?

2. are we clear that this is OK for XHTML content? Seems so - it's mentioned in 
HTML5 spec - but there's some question in my mind how this works vs. inline & 
link references to CSS. 

3. how does such a PI plays with the fallback-style attribute in spine item if 
this is an out-of-line XML Island? I think the latter is defined as CSS only, 
an xml-stylesheet often references XSL.

Several 2.x specs mention various things like opf packaage files need to be 
encoded as UTF-8 or UTF-16. Is UTF-16 applicable or can it be dropped for all 
specs?

i.e. video, audio streaming (media assets not part of the EPUB container) => 
internet connectivity required for full experience, but optional in the sense 
that the offline EPUB-embedded content remains accessible.

Is there is a use case to enable authors/publishers to provide, and reading 
systems to select, the optimal cover image for display from multiple images?

If the use case is valid, and images may vary by color range, dimension, 
resolution etc., then a method to differentiate images based on a property will 
be required on the manifest item.

Editor feels "future directions" in normative specs is unhelpful wrt the 
primary spec goals and plans to remove same (but not warnings about expectation 
of future removal of currently deprecated constructs which seem OK in 
moderation). Could say something as well in the EPUB3 Overview umbrella doc 
although Editor doubts whether it even should be there: specs can link to the 
WG webpage, and the WG webpage is where future directions info belongs. If you 
feel otherwise please comment on this issue.

Our first full working draft of EPUB (stable, complete) is scheduled for the 
end of Jan.

We've been referring to the 2 previous drafts as "internal working drafts" but 
we also have been saying they will not be private to WG members only, given our 
Google Code open source style model. IDPF has come in for some criticism wrt 
openness in the past - would it be preferable to use the term "Editors Draft" 
(as per W3C process) for these first 2 drafts?

The solution proposal for ops:type states that we will:
"Build a vocabulary that initially contains the items in Book Semantics. This 
vocabulary need not be normatively referenced from the OPS specification. 
However, at least informative spec references should be provided ..."

But it is not clear to me that this is will be the entire vocabulary for values 
for this attribute, and "need not be normatively referenced" and "at least 
informative" is a bit fuzzy about what is being proposed wrt content and UA 
conformance. 

Can someone clarify?

phrases like "X has a MIME media type Y" and "X is of MIME media type Y", and 
"X is a document with the MIME media type Y"  occur in the 2.0.1 specs.

Editor believes that since MIME media type is a type identifier for resources, 
not an intrinsic property of resources, saying that X "has" or "is of" or "is a 
document with" the MIME media type Y is simply shorthand for, in our system, 
"the value of the media-type attribute of X (or the manifest item that 
references X, as the case may be) is 'Y'". Just as in HTTP context it would 
mean "the HTTP request/response header for a GET of resource X has content-type 
Y".

But Editor would like confirmation that no additional semantics are attached to 
any of these phrasings. 

Note there is an explicit statement that all items that are Core Media Types 
must have resources that conform "as defined for" their MIME media types. I.e. 
we already have truthiness as a requirement(and I believe all the instances of 
these phrasings refer to instances of Core Media Types).

Also in at least one case the phrase is about a resource (package.opf) that 
explicitly cannot have a manifest item, so it's not clear what it signifies in 
this case.

Sec 2.3 of OPF 2.0.1 ends with: "A Content Document’s root element must be 
consistent with the media-type of the associated item element within the 
manifest."

Editor believes that this requirement is subsumed by the earlier statement in 
1.4.1.2 that "each file whose manifest entry identifies it as being in one of 
the OPS Core Media Types conforms as defined for those MIME type" (since every 
Content Document is considered to be of a Core Media Type, per the table in OPS 
1.3.7 and other prose), but it is phrased quite differently so if it means 
something additional/different please advise.

Due to the classic problem of ID/IDREF datatypes and rng:anyName.

The problem originates in xmldsig-core-schema.rng:

http://www.w3.org/Signature/2002/07/xmldsig-core-schema.rng 
conflicting ID-types for attribute "Id" of element "OriginatorKeyInfo" from 
namespace
"http://www.w3.org/2001/04/xmlenc#" Start location: 318:30

Once solved, also check that the schema actually is correct in terms of grammar 
after externalRef dereferencing (it doesn't look right to me).

(not discussed at F2F but a previous direction)

It is not particularly well defined in OPS 2.01

Adopt the caption/subtitle format specified by HTML5.  If HTML5 does not 
specify a format, specify TTML as the baseline format for caption/subtitles in 
EPUB (tentative).

People will be choosing to author HTML5 or OPS 3.0 content. HTML5 is a widely 
known and somewhat sexy term, OPS is not, nor it its spelled out term "Open 
Publication Structure" particularly meaningful or accurate given that it 
defines the content not the structure. Because we use the XHTML MIME type there 
is no compatibility issue relative to this name. So we could consider changing 
OPS to some other term as part of EPUB3, to improve our marketing and 
discourage unnecessary use of the HTML5 content type. "DTBook2", "HTML5 Plus", 
or "Reliable XHTML5"? (not serious proposals).

Issue per George K.

Mentions of content that can be optionally turned on/off appears in these text 
requirement use cases:
[TextContent#TE.01_Allow_for_inflection_of_domain-specific_semantics_on_top_o]

And in the concept of "skippability" in audio overlays:
[MediaOverlaySpec#The_ops:type_attribute]

Both cases imply that elements with certain ops:type semantics should be 
allowed to be optionally turned on or off by the user/reading system, but there 
is currently no mechanism through which a publication can expose what the 
options actually are.

The issue is to either create such a mechanism or recommend a method to reading 
systems of how to discover these options.

The OCF spec for EPUB 2.01 implies, though it does not seem to say explicitly, 
that files in META-INF need not (and should/must not?) be referenced by the 
manifest in the .opf file.  This is implied by the examples in the spec, by the 
fact that the URIs in the manifest are relative to the root of the OPF container

We should:

(a) clarify the above with an explicit statement to the effect that files in 
META-INF need not, and indeed SHOULD NOT be referenced in the manifest (maybe 
even MUST NOT?)

(b) provide guidelines to the effect that reading systems or other entities may 
use META-INF as a location in which to place custom files (e.g., a compiled 
index for a dictionary, or some proprietary extension file)

(c) provide guidelines to the effect that any entity using META-INF for such 
custom purposes should use reverse DNS-style naming conventions to avoid 
clashing with other proprietary uses of this space.

We decided only XHTML5 will be valid in EPUB Content Documents. So clearly 
unless we decree otherwise Reading Systems "may" reject content that's "street" 
aka "tag soup" HTML (the "HTML syntax" as it's called in HTML5 spec). If we 
don't want to see such invalid EPUB proliferate, and we don't, then Editor 
thinks this should at least be a "may reject" (i.e. we should not decree error 
handling rules that require accepting it) which would also be burdensome to 
Reading Systems that aren't browser-based.

But should we say more about this, for example that Reading Systems "should 
reject" or even "must reject" such non-XHTML (therefore invalid vs. our specs) 
content? Editor thinks "should reject" is a reasonable place to be, but seems 
like something WG might want to decide.

A bigger-picture question is general error handling rules. HTML5 has moved 
towards more tightly defined to be lenient requirements for User Agent error 
handling, although in some cases this contradicts XML's philosophy. We could 
say one thing about error handling for our own formats (package.opf, 
container.xml, NCX, etc.) but default to inheriting HTML5 rules for handling 
XHTML content. But inconsistent error handling rules for say badly formed XML 
in .opf vs. in xhtml content might be confusing. If our general rule for 
handling invalid content is "should reject" or "must reject" maybe HTML where 
XHTML is expected could just fall under that rule.

Rendering of Documents on Reading Systems (2.7) states that "...this 
specification does not mandate specific rendering behavior for the OPS 
Preferred Vocabularies..." and that "a number of elements and attributes permit 
semantics that are not required of all Reading Systems... In such cases this 
specification generally requires Reading Systems to accept all syntax (such as 
attribute values) permitted for the Preferred Vocabulary, but does not require 
that they be honored". 

This may be weaker than we'd like to see, since it means that a Reading System 
that "accepts" e.g. MathML and displays blank white spaces could be considered 
conformant. We could instead reference rendering requirements from derivative 
specs (HTML, SVG, MathML, etc.).

See comment in: 
http://code.google.com/p/epub-revision/wiki/ImplementationProposalsTTS

We have eliminated the term "OPS Content Documents" in favor of "EPUB Content 
Documents", so the term "ops" no longer has significance in our specs. We could 
certainly still use it as a prefix for "ops:role" attribute etc., but it would 
seem preferable to use "epub3" or "epub" or something else. 

Similar question for vendor prefix for our CSS3 additions, should it be 
"-epub3" or ?

Editor will draft with "epub3:" / "-epub3" for now.

This will be more significant if we need to take lots of things into our 
namespace en route (e.g. if HTML5 isn't done in time).

There needs to be a way to convey long descriptions to the user of things such 
as images, graphs, charts, data tables, etc.  The proposed attribute, 
ops:describedby, will reference external URIs and can be applied to any 
element, not just images.  Note:  if HTML5 defines its own version of 
describedby-- see http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455 for one 
proposal-- ops:describedby will become unnecessary and can be dropped.